智慧医院门诊系统Java源码解析：从数据库设计到并发控制实战

简介基于Java实现的智慧医院门诊管理系统项目适用于计算机专业毕业设计、课程设计及Java Web全栈开发学习者从项目搭建到功能实现均可复用。系统围绕预约挂号、就诊记录、药品管理、医生排班等核心模块展开覆盖从需求分析、数据库设计到接口开发、安全控制的完整流程。压缩包共包含289个文件以Java源文件、class编译文件、XML配置为主另有SQL脚本、设计文档、实验报告及详细说明资料整体大小48.14MB目录结构清晰便于按模块查阅。资源涉及MVC设计模式、Spring与Spring MVC、Hibernate/MyBatis持久化、RESTful API、前端页面、Spring Security安全控制及JUnit测试等关键技术点附带的文档与报告能帮助读者理解项目设计思路与实现细节。目前已有155人学习下载适合需要快速获取完整可运行项目参考的人群也适合课程答辩前对照梳理代码结构。1. 一套智慧医院门诊系统的压缩包解压之后才是真正的开始拿到基于java实现的智慧医院门诊管理系统项目源码设计文档实验报告详细资料.zip这类压缩包的人多半是三种身份做毕业设计的学生、刚转 Java 后端的初学者或者公司里要快速搭一套内部 demo 的开发者。打开压缩包之前很多人以为里面有完整源码就等于万事大吉真到解压那一刻才发现代码在 IDEA 里跑不起来的理由能列一长串——JDK 版本对不上、数据库脚本没导入、Redis 没启动、前端端口配错。这个项目标题看着是一份课程设计级别的交付物实际上它把能上课汇报和能落地运行之间的所有组件都塞进了一个 zip 里。这篇笔记要做的事就是把手里的这份原料按看清结构、跑通流程、写对文档、避开深坑的顺序拆开让你从解压到答辩都不慌。2. 先看清系统的骨架技术选型、数据库设计与源码包结构2.1 为什么智慧医院门诊管理系统普遍选 Java 系技术栈从 SSM 到 Spring Boot 的演进逻辑门诊管理系统属于典型的信息管理系统MIS业务集中在线下单据流转和状态管理上。这类系统对技术栈的要求不是性能极致而是成熟稳定、资料齐全、招人容易。Java 系在这里的核心优势是生态稳定Spring 家族对事务、权限、定时任务的支持非常成熟MyBatis 对复杂 SQL 的容忍度高官方文档和社区讨论足够多。做课设和毕设的人选 SSMSpring Spring MVC MyBatis是常见路径因为学校教材里教的就是这套而面向就业或实际交付的版本多数已经换成了 Spring Boot MyBatis Plus后者把配置量从 XML 堆里解放出来起步快得多。一个门诊管理系统如果按智慧二字做延伸通常会在基础挂号收费之外加入排队叫号大屏、预约时间段控制、医生排班、药品库存预警、以及面向管理者的统计报表。这些模块用 Java 后端来做技术上没有任何障碍难点全在数据一致性上——挂号号源不能超卖、退费不能把金额算错、排队状态不能乱跳。这是 Java 事务机制和锁最擅长解决的领域也是面试官和答辩老师最喜欢追问的地方。2.2 门诊数据库的表设计从患者建档到药品出库的 14 张核心表见过太多课设源码数据库只有四五张表患者、医生、挂号、收费就完事了。真正能撑起门诊管理系统这个名词的库表至少要覆盖患者、医生、科室、排班、号源、挂号、排队、处方、收费、退费、药品、库存、用户、日志这 14 个核心实体。表与表之间的关系也不复杂核心链路是患者建档 - 科室排班 - 取号挂号 - 排队叫号 - 医生开处方 - 收费处结算 - 药房扣库存。以挂号环节的表结构为例最容易被忽略的是号源表和挂号记录表要分开建。很多人图省事直接在挂号记录表里判断剩余号数导致取消挂号、退号之后号源计数对不上。正确做法是一张 schedule 表记录某医生某天上午放多少号一张 registration 表记录实际挂出的号两张表通过 doctor_id 和 schedule_date 关联。下面这段 SQL 是核心两张表的常见建法CREATE TABLE schedule ( id BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT 排班ID, doctor_id BIGINT NOT NULL COMMENT 医生ID, dept_id BIGINT NOT NULL COMMENT 科室ID, schedule_date DATE NOT NULL COMMENT 出诊日期, time_slot TINYINT NOT NULL COMMENT 时段 1上午 2下午, total_number INT NOT NULL DEFAULT 30 COMMENT 总号源数, remain_number INT NOT NULL DEFAULT 30 COMMENT 剩余号数, version INT NOT NULL DEFAULT 0 COMMENT 乐观锁版本号, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ) COMMENT 医生排班表; CREATE TABLE registration ( id BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT 挂号ID, patient_id BIGINT NOT NULL COMMENT 患者ID, schedule_id BIGINT NOT NULL COMMENT 排班ID, visit_no VARCHAR(32) NOT NULL COMMENT 就诊号, status TINYINT NOT NULL DEFAULT 1 COMMENT 1待就诊 2已就诊 3已退号, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_schedule_visit_no (schedule_id, visit_no) ) COMMENT 挂号记录表;这段 SQL 里有几个参数值得说明。time_slot 用 TINYINT 而不是 VARCHAR是为了后续统计上午放了多少号、下午放了多少号时避免字符串比较的性能损耗。visit_no 用 VARCHAR(32) 存储就诊号生成规则建议做成日期 科室编码 序号比如 20250612-GH-001可读性和唯一性都好直接用数据库自增 ID 当就诊号的话前端的排队叫号大屏上会显示一串毫无意义的大数字。version 字段是留给并发控制的后面第三章会讲具体用法。数据库统一用 InnoDB 引擎字符集用 utf8mb4 而不是 utf8。这个坑必须提前说MySQL 的 utf8 是 utf8mb3 的别名存不了 emoji 和部分生僻汉字患者姓名里一旦出现这类字符插入直接报错或者变成问号。课设测评现场出这种问题非常尴尬。2.3 源码包目录结构拿到压缩包之后按什么顺序读代码解压之后先别急着点运行按钮花五分钟确认一下目录结构。常见的门诊管理系统源码包无论基于 SSM 还是 Spring Boot代码组织上都有固定套路。后端按 controller、service、mapper、entity、config 分层前端可能是 JSP、Thymeleaf 模板或者独立 Vue 工程数据库脚本通常放在 sql 或 doc 目录下设计文档和实验报告在各学院的命名习惯里可能是需求分析.docx设计说明书.docx实验报告.docx。我一般会按这个顺序读代码先读 pom.xml 或 build.gradle 确认依赖版本再读 application.yml 或 application.properties 看数据库和中间件配置然后看 sql 目录里的建表脚本是否和实体类字段一一对应最后才去看 controller 层暴露了哪些接口。一个非常实用的检查技巧是在 IDEA 里用全局搜索功能搜 RequestMapping把所有接口路径列出来和设计文档里的功能模块清单做对比——模块数量对不上说明代码和文档不是同一版这种货不对板的情况在网上下载的压缩包里出现概率非常高。find . -name *.java | xargs grep -l RestController\|Controller | sed s|^\./|| | sort上面这条命令在 Linux 或 Git Bash 里跑一下能快速拿到所有 Controller 类的文件路径。跑出来的结果如果和下面这个目录结构相差太远就要谨慎一点——说明源码的模块划分方式和常规做法有出入需要额外花时间搞清楚它的路由是怎么组织的src/main/java/com/hospital/outpatient ├── controller │ ├── LoginController.java │ ├── RegisterController.java │ ├── QueueController.java │ └── ChargeController.java ├── service │ ├── ScheduleService.java │ ├── RegistrationService.java │ └── PrescriptionService.java ├── mapper │ ├── ScheduleMapper.java │ ├── RegistrationMapper.java │ └── DrugStockMapper.java ├── entity │ ├── Schedule.java │ ├── Registration.java │ └── Patient.java └── config └── WebConfig.java读代码的时候要带着问题读而不是逐行看。第一个问题是登录鉴权怎么做的用没用到拦截器或 Spring Security第二个问题是挂号时号源扣减写在哪一层是 controller 里直接 update 还是 service 里加了事务第三个问题是前端页面和后端接口的联调方式是服务端渲染还是前后端分离。这三个问题搞清楚整个系统的运行逻辑就通了八成。3. 把核心流程跑通挂号、排队叫号与收费退费的代码实现3.1 当日挂号与预约挂号的事务边界一个接口把号源扣减和挂号记录写入做成原子操作门诊系统的核心业务流程是挂号。挂号在代码层面完成两件事从 schedule 表的 remain_number 里扣掉一个号往 registration 表插入一条挂号记录。这两件事要么都成功要么都失败否则就会出现号扣了但记录没生成、或者记录生成了但号没扣的脏数据。这就是典型的事务边界。用 Spring Boot 实现时在 service 方法上加 Transactional 注解是最常见的做法。但事务注解只解决了异常回滚的问题解决不了并发超卖的问题。两个患者同时挂最后一个号两个请求都读到 remain_number 1都执行 update 减一最后可能出现两条挂号记录共用同一个号源这就是超卖。解决超卖有两个常规思路一是数据库层面的悲观锁SELECT ... FOR UPDATE二是乐观锁UPDATE 语句里带版本号条件。Service public class RegistrationService { Resource private ScheduleMapper scheduleMapper; Resource private RegistrationMapper registrationMapper; Transactional(rollbackFor Exception.class) public Long register(RegisterRequest request) { // 1. 尝试扣减号源利用乐观锁版本号避免超卖 int rows scheduleMapper.deductNumber( request.getScheduleId(), request.getExpectedVersion()); if (rows 0) { throw new BizException(号源已被抢完或排班已变更请刷新后重试); } // 2. 生成就诊号并写入挂号记录 String visitNo generateVisitNo(request.getScheduleId()); Registration reg new Registration(); reg.setPatientId(request.getPatientId()); reg.setScheduleId(request.getScheduleId()); reg.setVisitNo(visitNo); reg.setStatus(1); registrationMapper.insert(reg); return reg.getId(); } }对应的 Mapper XML 里的扣减语句是这样写的update iddeductNumber UPDATE schedule SET remain_number remain_number - 1, version version 1 WHERE id #{scheduleId} AND remain_number 0 AND version #{expectedVersion} /update这段代码的关键在 update 语句的 WHERE 条件remain_number 0 是防止扣成负数version #{expectedVersion} 是保证操作基于最新状态。调用方先查一次 schedule 拿到当前 version然后带着这个版本号去执行更新如果版本号对不上说明有别人已经改过了更新影响行数为 0业务层直接抛异常。这样既不需要给数据库行加锁又能保证并发安全是课设和实际项目中都很稳妥的做法。注意 Transactional(rollbackFor Exception.class) 里的 rollbackFor 必须写否则 RuntimeException 以外的异常不会触发回滚。3.2 排队叫号的状态机设计从待就诊到已就诊的状态流转怎么写不打架排队叫号模块常被当成一个查询接口加一个页面来做实际上它是整个系统里最容易出逻辑漏洞的地方。患者挂完号之后的就诊状态有多个节点待就诊、已叫号、已就诊、过号、已退号。每个节点之间的流转方向是固定的已就诊不能退回待就诊已退号不能再叫号。如果不把状态流转管起来就会出现医生点下一个时叫到已经看完的患者。常见做法是引入一个简单的状态机用 status 字段和一组前置状态校验来控制流转。以下代码展示叫号接口的核心逻辑public QueueResult callNext(Long deptId) { // 1. 找到当前科室排队中的第一个患者 Registration next registrationMapper.findFirstWaiting(deptId); if (next null) { return QueueResult.empty(当前没有等待患者); } // 2. 校验状态只有待就诊(1)的患者可以被叫号 int rows registrationMapper.updateStatus( next.getId(), Constants.STATUS_WAITING, // 期望当前状态 Constants.STATUS_CALLED); // 目标状态 if (rows 0) { throw new BizException(该患者状态已变化请刷新队列); } return QueueResult.of(next.getVisitNo(), next.getPatientName()); }updateStatus 方法里的 SQL 类似这样UPDATE registration SET status #{targetStatus} WHERE id #{id} AND status #{expectedStatus}这个写法的好处是状态更新通过 WHERE 条件里的期望状态做乐观控制两个人同时操作同一条挂号记录时只有一个会成功。叫号大屏的轮询接口只查询 status 1待就诊和 status 2已叫号的记录不轮询已就诊数据可以显著减少无效查询。这里要特别注意的一点是过号逻辑要单独设计过号患者不能被简单删除而是要把状态改为过号并允许医生在队列空闲时手动把它重新置为待就诊这类特殊流程在测试阶段经常被遗漏。3.3 收费退费与金额计算BigDecimal 的正确使用姿势门诊收费模块涉及处方金额计算、收费记录生成、退费时按原路冲正三个环节。Java 里做金额计算必须用 BigDecimal不能用 double 或 float。这不是什么高级优化而是基础常识double 的二进制浮点表示无法精确表达 0.1多个金额累加会出现 0.30000000000000004 这类结果。金额计算最常见的错误是用 new BigDecimal(0.1) 这种构造方式。这个构造方法接收 double 类型参数传入 0.1 之后得到的实际值是 0.1000000000000000055511151231257827021181583404541015625后面所有的计算结果都会被这个误差污染。正确做法是 new BigDecimal(0.1)用字符串构造或者用 BigDecimal.valueOf(0.1)后者内部也是先转字符串。public ChargeResult charge(ChargeRequest req) { // 汇总处方项目金额每一项的单价和数量都是字符串形式传入 BigDecimal totalAmount BigDecimal.ZERO; for (ChargeItem item : req.getItems()) { BigDecimal unitPrice new BigDecimal(item.getUnitPrice()); BigDecimal quantity new BigDecimal(item.getQuantity()); totalAmount totalAmount.add(unitPrice.multiply(quantity)); } // 保留两位小数四舍五入 totalAmount totalAmount.setScale(2, RoundingMode.HALF_UP); // 写入收费记录并更新处方状态 ... }setScale 的第二个参数 RoundingMode.HALF_UP 表示四舍五入这是医院收费场景的标准处理方式。同时要注意数据库里金额字段用 DECIMAL(10,2)不要用 FLOAT 或 DOUBLE否则 Java 层算得再准存进数据库也会丢精度。退费场景比收费更坑。退费不能简单地把收费记录删掉而是应该新增一条金额为负的冲正记录保留完整的审计链路。这在设计文档和实验报告里通常会被单独拿出来讲因为它是数据一致性和可追溯性的典型代表。4. 把设计文档和实验报告写出质量从目录结构到答辩话术4.1 设计说明书怎么写才不像是抄的需求分析、数据库设计与接口文档的闭环压缩包里设计文档这个文件是很多人的救命稻草也是很多人翻车的地方。直接拿网上下载的模板改个标题就交上去导师和答辩老师一眼就能看出来。设计文档的核心不是格式多漂亮而是三个部分要形成闭环需求分析里写的功能数据库设计里要有对应的表数据库设计里建的表代码里要有对应的实体类代码里实现的接口接口文档里要有对应的描述。我见过太多人的设计文档里写了十个功能模块结果系统里只有五个能跑通。答辩老师随便点一个系统管理里的角色权限分配功能你在现场演示不出来整份文档的可信度就崩了。写设计文档的正确路径应该是先把系统里真正能跑的功能列出来再按这些功能去组织文档目录。常规章节包括项目背景与意义、需求分析功能需求加用例图、系统总体设计架构图加技术选型、详细设计每个模块的流程说明加核心类图、数据库设计ER 图加关键表结构说明、系统测试。其中数据库设计部分把表结构写清楚就够了不用把每张表的所有字段都罗列一遍挑核心的 schedule、registration、charge_record 三张表做详细说明其他表一笔带过即可。4.2 实验报告不是写作文测试用例表是最省力又最占篇幅的部分实验报告和设计文档不同设计文档重在设计思路实验报告重在验证过程。很多人的实验报告写得像产品说明书把每个页面截个图贴上去配一句系统运行正常这等于没写。实验报告的核心是测试用例表——输入什么数据预期什么结果实际得到什么结果测试结论是什么。这是一份可以量化的记录也是评委判断你到底有没有把系统跑起来的关键证据。功能模块门诊挂号 测试用例编号TC-HANGHAO-001 前置条件医生排班存在号源剩余 5 个 操作步骤 1. 进入挂号页面选择该医生与当天日期 2. 填写患者姓名、身份证号 3. 点击确认挂号 预期结果挂号成功就诊号生成号源剩余 4 个 实际结果挂号成功就诊号 20250612-GH-005号源剩余 4 个 测试结论通过至少写十五到二十条这样格式的测试用例覆盖正常流程和异常流程各一半。异常流程要有代表性比如重复挂号、退号后再次挂号、号源为 0 时挂号、并发挂号、药品库存不足时开处方。这些异常流程能和第三章的代码实现一一对应上实验报告和源码就形成了一个完整的证据链。我在帮人改实验报告时最常做的一件事就是删掉那些大段的功能介绍文字替换成这种结构化测试用例页面篇幅一点不少信息密度高得多。4.3 答辩复盘八股文之外的实战问题怎么接答辩时老师提的问题有相当一部分是套路化的 java 八股文比如 Spring 事务的传播机制有哪些、MyBatis 中 #{} 和 ${} 的区别、HashMap 的底层实现。这些靠背題能应付但真正容易挂掉的是以下几类实战问题第一类针对你的项目本身号源扣减这段代码在高并发下会出现什么问题你是怎样解决的这个问题直接对应 3.1 节的乐观锁方案。回答时要主动说出乐观锁的劣势——并发冲突多时大量请求会因为版本号不一致而失败用户体验差生产环境通常会改用 Redis 分布式锁或数据库悲观锁。第二类是需求追问如果一个患者挂完号又退号了号源要不要恢复什么时候恢复这个问题考察的是业务细节思考。如果退号发生在当天号源应该恢复但要考虑时间段是否已过如果发生在预约阶段则直接恢复号源。第三类是部署问题你这个系统的服务器环境是怎样的数据库怎么部署的回答时要把 Tomcat 端口、MySQL 连接串、文件上传路径这些细节说清楚对部署过程越熟悉越证明系统是你自己搭起来的。5. 避坑与排错从登录失败到并发超卖五个高频问题的排查路径5.1 数据库时间比本机慢了 8 小时挂号记录总是落在昨天现象页面新增的挂号记录在数据库里 create_time 显示为前一天的时间或者预约日期的判断总是错一天。在控制台手动执行 SQL 插入当前时间发现数据库服务器的时间是正确的。原因JVM 默认时区和数据库会话时区不一致。MySQL 的 JDBC 连接串如果没有显式指定 serverTimezone会用数据库服务器的系统时区做时间转换而应用的 Tomcat 运行在本机本机时区是东八区两边一换算就差了 8 小时。大多数情况下不是代码问题是连接参数问题。解决在 application.yml 的数据库连接串里显式加上 serverTimezone 参数。这种做法一劳永逸避免以后部署到不同时区的服务器上再踩一遍。spring: datasource: url: jdbc:mysql://localhost:3306/outpatient?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai配置完之后重启应用再插入一条记录验证时间。注意这个坑在开发机上不一定出现因为很多人开发时库和应用在同一台机器上时区一样看不出问题换到云服务器或者别人的电脑上才暴露。5.2 登录接口一直报 404Controller 路径和方法上都没问题现象登录页面能打开输入账号密码点登录浏览器开发者工具显示请求状态码 404。检查 Controller 的 RequestMapping 路径和页面里提交的 action 或 axios 请求地址完全一致方法名、参数名也没有问题。原因404 是最容易被误判成代码问题的部署问题。最常见的原因是前端页面和后端应用不在同一个端口下——前端跑在 8081后端跑在 8080前端发出的请求没有带 web 应用的 context-path。另一种常见的情况是 Spring Boot 内嵌 Tomcat 的 context-path 配置了 /outpatient后端接口实际路径是 /outpatient/login而前端只请求了 /login。解决先看浏览器开发者工具 Network 面板里请求的完整 URL把端口号之前的路径部分和后端 application.yml 里的 server.servlet.context-path 配置对齐。如果前后端分离需要在开发环境配置代理转发把 /api 前缀的请求代理到后端端口。这种问题属于排查顺序问题自上而下对准 URL 和端口比盯着代码干看有效率得多。5.3 挂号并发压测出现超卖加 Transactional 也没用现象用 JMeter 模拟 100 个并发请求同时挂号同一个医生号源号源设置为 5压测结束后发现挂号记录数超过 5 条。原因Transactional 只解决了事务原子性没解决并发隔离性。MySQL InnoDB 默认隔离级别是 REPEATABLE_READ多个事务同时读取 remain_number 5各自在事务里执行 UPDATE 减一只要不加锁或加版本号校验后执行的事务会覆盖先执行的结果最终票数多扣或超卖。事务能保证操作要么全成功要么全失败但保证不了多个线程按顺序执行。解决把 3.1 节的乐观锁方案应用到实际代码里或者改用悲观锁 SELECT ... FOR UPDATE拿 排队叫号模块优先处理。顺带说做课设时只要把乐观锁写进代码这个并发问题的答案就完整了——面试官想听的也不是你用了 Redis而是你理解并发环境下单纯加事务不够用。5.4 文件上传的附件路径存的是绝对路径换个电脑就找不到图片现象系统在其他电脑上部署后患者头像、药品图片等上传文件全部无法显示数据库里存的 URL 访问报 404。原因开发时把上传文件保存在了本地绝对路径下比如 D:/upload/xxx.jpg代码里写死了这个路径。换一台电脑运行这个目录不存在文件写到新目录但数据库里的旧路径还是指向 D 盘自然找不到。解决上传路径应该做成配置项放在 application.yml 里部署时按实际环境修改。同时数据库里存储相对路径前端访问时通过虚拟映射拼接完整地址。配置虚拟路径映射是常见做法代码如下Configuration public class WebConfig implements WebMvcConfigurer { Value(${file.upload-dir}) private String uploadDir; Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/upload/**) .addResourceHandler(file: uploadDir /); } }注意 /upload/** 是前端访问 URL 前缀file: uploadDir 是磁盘实际路径两者通过映射关联起来。这样代码里不出现任何硬编码路径部署到 Linux 服务器只需要把 upload-dir 改为 /home/outpatient/upload 即可。5.5 前端页面样式加载不出登录页光秃秃的只有文字现象登录页面能打开但 CSS、JS 文件全部加载失败控制台报 404 错误。项目是基于 JSP 或 Thymeleaf 的服务端渲染模式。原因静态资源没有正确映射。Spring Boot 默认把 classpath:/static/ 作为静态资源目录如果项目把静态资源放在了 webapp 目录或者类路径下没有 static 目录静态资源就找不到。另一个高频原因是资源路径写错了相对路径页面在根路径下能打开跳转到子路径后相对路径失效。解决静态资源统一放在 src/main/resources/static 下页面引用使用绝对路径也就是以 / 开头的写法。在 Thymeleaf 模板里推荐用 {} 表达式自动拼接 context-path这样即使部署到带项目名的容器下也不会出错。link relstylesheet th:href{/css/login.css} script th:src{/js/app.js}/script排查时先直接用浏览器访问静态资源地址如果能打开说明映射正常问题出在页面引用路径如果打不开说明映射配置有问题。这个排查方法比改代码快得多。6. 进阶技巧与验证把课设级别代码练成拿得出手的项目6.1 挂号的并发量上去了从乐观锁到 Redis 分布式锁的升级路径课设答辩现场你把乐观锁方案讲出来已经能过关。但如果你真要拿这套系统去面试或者做项目展示会被追问一个问题乐观锁版本冲突严重怎么办乐观锁适合读多写少的场景一旦并发写操作多大量请求因为版本号不一致而失败用户看到一堆操作失败请重试体验很差。生产环境处理挂号秒杀这类场景常用做法是 Redis 分布式锁。用 Redis 实现分布式锁的经典写法是 SET key value NX EX 命令加 Lua 脚本释放锁。Java 项目里用 Spring Data Redis 的 RedisTemplate 实现如下public boolean tryLock(String key, String requestId, long expireSeconds) { return redisTemplate.opsForValue() .setIfAbsent(key, requestId, Duration.ofSeconds(expireSeconds)); } public boolean releaseLock(String key, String requestId) { // 用 Lua 脚本保证判断和删除是原子操作 String script if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end; DefaultRedisScriptLong redisScript new DefaultRedisScript(script, Long.class); Long result redisTemplate.execute(redisScript, Collections.singletonList(key), requestId); return Long.valueOf(1L).equals(result); }使用时的核心逻辑是在挂号入口处加锁锁的粒度要到排班 ID不然锁整个表的性能损耗毫无必要。锁释放放在 finally 块里防止业务异常导致死锁。这个技巧在面试时的价值在于展示你对并发场景的思考深度——从单体应用的乐观锁到引入 Redis 作为分布式协调组件每一步都有清晰的业务动机。6.2 性能验证用 JMeter 给挂号接口做压测的三个核心指标功能跑通之后要学会验证系统能不能扛住门诊高峰时段的流量。门诊系统的并发峰值通常在上午 8 点到 10 点一个中等规模的社区医院在这个时段内可能要处理几百到上千次挂号操作。用 JMeter 做压测时重点关注三个指标TPS每秒事务数、平均响应时间、错误率。TPS 代表系统吞吐能力平均响应时间代表用户体验错误率代表稳定性。JMeter 压测配置里要注意把线程数、循环次数、持续时长设置合理。不要一上来就 1000 个线程压先 50 并发跑 5 分钟看 TPS 是否平稳再逐步加压到 100、200观察系统什么时候开始出现错误或响应时间陡增。压测结果记录到实验报告的测试章节里比任何文字描述都有说服力。对课设项目来说50 并发下 TPS 能到 20 以上错误率为 0已经是不错的成绩。压测之前把 MySQL 的最大连接数调大一点默认的 100 很容易成为瓶颈。同时确认 Tomcat 的最大工作线程数Spring Boot 默认是 200在 application.yml 里配置 server.tomcat.threads.max 可以调整。这两个参数是压测效果的分水岭很多人压测结果难看不是代码问题是容器配置没调过。6.3 一份值得长期保存的部署检查清单做完上述所有事情之后把系统部署到服务器上做一次完整的可用性验证。我的习惯是维护一份部署检查清单每次启动新环境时照着走一遍数据库初始化脚本是否完整执行、Redis 是否已启动且连接密码是否配置、上传目录是否存在且有写权限、时区和数据库连接参数是否匹配、防火墙是否放行了 8080 端口。清单上的每一项都有对应的验证命令比如检查上传目录权限用 ls -l检查数据库连接用端口连通性测试。这套系统的价值不在代码量而在数据模型和业务完整性上。Java 这个方向的学习路径从基础语法到 Spring Boot、从 SSM 到微服务门诊管理系统刚好是一个能把所有基础组件串起来的综合案例。我给自己的要求是任何时候拿到一个项目先跑通再优化最后才谈扩展。跑都不跑不起来的代码任何性能优化和架构设计都是空中楼阁。这些年带过的学生里能把课设代码里的乐观锁、状态机、BigDecimal 精度处理讲清楚的人面试时普遍比那些简历上写着精通高并发的人更让面试官信服。希望这篇笔记能帮你在解压那个 zip 之后不只是拿到一个能交差的程序而是真正理解一套业务系统从设计到落地的完整链路。本文还有配套的精品资源点击获取