是个少女最近又有几个同学拿着同样的题来找我——SpringBoot医疗预约挂号系统。这个题目看起来就是一个常规管理系统，但你真正动手就会发现，挂号系统的核心难点根本不在增删改查上，而在号源和并发。同样是做毕设，有人交出来的是"能登录、能增删改查"的初级系统，有人交出来的是"预约、锁号、就诊、评价完整闭环"的加分作品。这篇文章我把自己做过、带过的几个相似项目整理了一遍，从数据库建模、并发锁号、医患交互到最终的演示答辩，把这条线完整捋清楚，给正在做或者打算做这个题目的同学一份可以直接上手的参考。
1. 拆解题目：挂号系统的"挂号"二字才是灵魂
1.1 隐藏在长标题里的三个能力域
计算机毕业设计springboot医疗预约挂号系统，加上副标题里的"Java Web医院在线预约诊疗服务平台"和"门诊智能预约与医患交互系统"，本质上是在说三件事：第一，这是一套基于Java Web技术栈的在线预约诊疗平台；第二，它要能完成门诊智能预约，也就是真正管理号源的挂号能力；第三，它需要包含医患交互，不仅是预约，还有诊前咨询、诊后随访和评价。
很多同学把这三件事做浅了。平台能力做成了一套普通的增删改查，预约能力做成了往订单表里插数据，医患交互更是干脆没做。实际上面向评委的完整项目，必须把这三块都撑起来。
平台能力对应的是科室、医生、排班、号源、订单、病历这些基础数据的管理；预约能力是整个系统含金量最高的部分，它要解决"号源不超卖、不重复、可取消、可回补"这一系列核心问题；交互能力则是把预约和就诊连接起来，让患者、医生、管理员三方在一个系统里完成完整的信息流转。
1.2 三种角色和一条业务闭环
系统里至少要有三种角色：患者、医生、管理员。分开看，每类角色的功能诉求完全不一样。
患者端需要的是：注册登录、浏览科室和医生信息、查看可预约排班、提交预约、取消预约、查看我的订单和病历、给医生留言、对就诊进行评价。这些功能服务于一个核心诉求——用最少的操作挂上号。
医生端需要的是：查看自己的排班表、查看某个时间段已经预约的患者列表、开始接诊并书写病历、回复患者的留言、查看患者评价。这些功能服务于医生的日常门诊工作。
管理员端需要的是：维护科室信息、管理医生账号、发布和调整排班计划、设置每天的放号数量、查看预约统计报表。这套功能服务于整个平台的运转。
三条线的闭环是这样的：管理员发布排班后，患者在线浏览并预约，医生在门诊时间接诊并填写病历，就诊结束患者可以查看病历并评价。对这个闭环理解得越清楚，后面数据库设计和接口设计就越不容易跑偏。
1.3 功能边界：哪些必须做，哪些果断砍掉
毕设有时间限制，我建议核心做五大模块，另外四类功能直接砍掉或换成简化版本。
| 建议保留 | 建议砍掉或简化 |
|---|---|
| 登录注册与RBAC权限控制 | 真实第三方支付（用模拟支付替代） |
| 科室、医生、排班信息管理 | 真实短信验证码（用站内信替代） |
| 号源预约、取消、回补 | 对接LIS/PACS等医院信息系统 |
| 医患留言、病历、评价闭环 | 微信小程序或APP双端 |
| 后台统计报表（可选ECharts） | 在线视频问诊等过度复杂交互 |
砍掉不等于放弃亮点，而是先把主线打通。我见过太多同学把两周时间花在集成短信接口、对接支付上，最后核心的并发挂号逻辑一塌糊涂，答辩现场一追问就露馅。主线做扎实了，再加亮点不迟。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 技术组合怎么定：选对了，后面能省一半时间
2.1 框架选型：SpringBoot解决的是"脚手架"问题
既然题目直接点名了SpringBoot，那框架层面基本没有悬念。SpringBoot在毕业设计里几乎是标准答案，原因很实在：
第一，自动配置让环境搭建成本极大降低。传统Spring项目要配置一堆XML、手动部署到外部Tomcat，SpringBoot内嵌容器，一个启动类就能把整个项目跑起来。对做毕设的同学来说，这省掉的不是一两天，而是一个量级的时间。
第二，生态成熟度高。MyBatis Plus、Redis、Sa-Token、Shiro、MinIO这些常见组件都有开箱即用的封装，网上案例一搜一大把，遇到问题基本都能找到答案。第三，用SpringBoot写出来的分层代码本身就更贴近当前企业开发主流，放到简历上也不寒碜。
2.2 存储与中间件：MySQL是基本盘，Redis是加分项
数据库选MySQL 8.0就够了。毕设场景下MySQL资料最多、排查问题最方便，没有必要追求Oracle或者PostgreSQL。要注意的是建库时统一字符集用utf8mb4，否则存中文和特殊符号会出现乱码。
Redis要不要上？我的建议是：如果你想把并发锁号讲出深度，就上。Redis在这个系统里能在三个位置发挥作用：缓存科室和医生列表、用Lua脚本原子扣减号源、管理Token黑名单。但如果时间实在紧张，数据库乐观锁也完全能做并发控制，答辩时把逻辑讲清楚，然后主动提一句"生产环境可以引入Redis做预扣减"，效果也不会差。
2.3 工程分层：Controller、Service、Mapper这套不丢人
SpringBoot项目虽然代码结构不强制，但一套清晰的工程分层对答辩很重要。
- controller：接收请求、参数校验、封装统一返回结果
- service：业务逻辑层，事务边界全部在这层管理
- mapper：MyBatis Plus的BaseMapper，简单CRUD不用手写SQL
- entity / dto / vo：数据库实体、出入参对象、视图对象分开
- common：统一返回体、全局异常处理、各种工具类
- config：跨域配置、拦截器注册、Redis配置
这里有一条铁律：不要把业务逻辑写在Controller里。那种一个Controller里几百行代码直接查库的写法，答辩时被问一句"事务边界在哪"就很难自圆其说。把状态流转、并发控制、事务管理都收进Service层，是代码质量最直观的体现。
2.4 前端方案：Vue3结合Element Plus更稳妥
如果前端基础一般，用Thymeleaf加Bootstrap也能做出一版可用的系统，但我更推荐Vue3加Element Plus加Axios加Pinia这套组合。原因有三个：前后端分离架构本身就是一个可讲的亮点；Element Plus的表格、表单、对话框、日期选择器开发后台页面效率极高；路由守卫天然适合做角色权限区分，比在JSP里写判断逻辑优雅得多。
前端用脚手架初始化后，重点把路由、请求封装、页面组件三块写好。页面不要贪多，患者端、医生端、管理端各五六张核心页面就够撑起演示了。
3. 表结构：挂号系统最容易被问倒的一张ER图
3.1 核心表的字段怎么设计
数据库设计是评审老师几乎必盯的部分。我建议项目至少设计以下九张核心表：
| 表名 | 作用 | 关键字段 |
|---|---|---|
| sys_user | 统一用户表 | id, username, password, real_name, phone, role, create_time |
| department | 科室表 | id, dept_name, dept_desc, status |
| doctor | 医生信息表 | id, user_id, dept_id, title, intro, reg_fee, status |
| doctor_schedule | 医生排班表 | id, doctor_id, work_date, period, total_count, remain_count |
| appointment | 预约订单表 | id, order_no, user_id, doctor_id, schedule_id, status, reg_fee, create_time, cancel_time |
| medical_record | 病历表 | id, appointment_id, diagnosis, advice, prescription, create_time |
| consultation | 医患留言表 | id, appointment_id, user_id, doctor_id, content, reply, reply_time |
| evaluation | 评价表 | id, appointment_id, user_id, rating, content, create_time |
| notification | 站内通知表 | id, user_id, title, content, is_read, create_time |
sys_user用role字段区分患者、医生、管理员三种角色，不拆成三张用户表。好处是登录认证只要查一张表，权限逻辑也简单，在真正的用户量很大的场景下可能会拆表，但毕设这个体量下，一张用户表加角色字段是合理且好讲的设计。
doctor表独立出来是因为医生有职称、简介、挂号费等专业属性，而且一个用户账号对应的是一份医生个人信息，这样的拆分符合数据库规范化要求。
3.2 排班表的两个关键字段
doctor_schedule是这套系统里最值得细讲的表。一条排班记录的含义是：某个医生在某一天、某个半天坐诊，放出了多少个号源，还剩多少个。period用1表示上午、2表示下午，total_count是总号源数，remain_count是剩余号源数。
预约的本质操作就是扣减remain_count。总号源和剩余号源分开存，是为了统计和历史回溯。如果只存一个"剩余量"字段，想查某个排班发过多少号就得去订单表里数，费劲且不直观。
还应该给doctor_schedule加上联合唯一索引，约束(doctor_id, work_date, period)，从数据库层面保证同一个医生同一天同一个半天只能有一条排班记录，这是杜绝脏数据的底层防线。
3.3 预约记录与状态机设计
appointment表是整个系统最核心的订单表。order_no每次生成时加上时间戳和随机数，并建唯一索引。status字段用整数表示：0待支付、1已预约、2已完成、3已取消、4爽约。
有两点设计容易忽略。一是取消回补号源的更新操作要带状态条件，防止重复取消导致号源被回补两次。二是状态字典不要用魔法数字，写成枚举类，代码里只出现AppointmentStatus.CANCEL这样的语义化命名，否则六个月后你自己都看不懂3是什么状态。
所有状态切换逻辑集中放到Service层。我习惯在Service里写一个专门的cancelAppointment方法，内含状态校验、号源回补、通知生成的完整事务，不让状态散落在各个调用方。
3.4 索引设计的思路
必加的几个索引：appointment表的user_id加status的组合索引，支撑"我的预约"高频查询；order_no唯一索引防止重复订单号；appointment表的schedule_id加appoint_date便于排查某个排班的预约详情；doctor_schedule表上面的联合唯一索引。
答辩时被问"为什么这里有索引"，不要只回答"查询快"。要能说出更完整的意图：索引不只是加速读取，更重要的是通过唯一索引在数据库层面维护业务规则的完整性。这种回答方式比背概念有说服力得多。
4. 预约挂号的核心链路：这一步做到位，项目直接上一个档次
4.1 排班发布：号源从无到有
管理员发布排班的流程是：选择医生、选择日期、选择上午或下午、填写放号总量，保存时校验当前排班是否已存在，存在则提示冲突，不存在则生成schedule记录，total_count等于本次放号量，remain_count同步初始化为相同值。
如果一套系统只能一条一条地手动录入排班，演示效果会很平庸。我建议加一个批量生成功能：管理员选定医生和起始日期，勾选未来一周的周几、上午还是下午坐诊，一次生成多条排班记录。这个功能代码量不大，但演示时画面感很强，一个按钮生成一周的排班。
4.2 患者下单：经典的三级选择
患者预约页面的核心流程是"选科室、选医生、选时间"三级联动。对应的后端接口很清晰：
- 查询科室列表
- 根据科室ID查询医生
- 根据医生ID查询可预约排班，返回日期、时间段、剩余号源数
前端用Element Plus的级联选择器或者分步表单都能实现。需要注意页面提交时不要只传scheduleId，还要传uid和当前排班的版本信息，后端要在这个基础上做最终校验。剩余号源在前端展示归展示，能不能抢到号，完全由后端最后一次扣减决定。
4.3 锁号：两个患者同时抢最后一个号怎么办
这是整个项目技术含量最高、最值得写进毕业论文的一段。
我推荐方案是这样的，后端Service方法加上@Transactional，里面先执行一行核心SQL：
sql复制UPDATE doctor_schedule
SET remain_count = remain_count - 1
WHERE id = #{scheduleId}
AND remain_count > 0
然后判断执行结果，影响行数等于1，说明抢号成功，接着插入预约记录；影响行数等于0，说明号源已经为空或者排班状态异常，直接抛出业务异常返回"号源不足"。
为什么这一行SQL能防超卖？因为UPDATE在数据库层面是行级锁操作。当多个线程同时更新同一行记录时，数据库会让它们串行执行。号源剩1时，两个请求同时到来，第一个执行成功后remain_count变成0，第二个再执行时条件remain_count>0不满足，影响行数就是0。后到的请求不会插入订单，号源不会被扣成负数。如果条件里不写remain_count>0，就可能出现扣成负数再回滚，这就是超卖。
如果你已经用了Redis，可以再进一步把扣减逻辑写成Lua脚本：
lua复制local remain = redis.call('GET', KEYS[1])
if tonumber(remain) > 0 then
redis.call('DECR', KEYS[1])
return 1
else
return 0
end
用Lua脚本保证"查询、判断、扣减"三步原子操作，再配合数据库事务落单，这就形成了一套"Redis抗并发扣减、数据库兜底一致性"的双层设计。答辩时能讲出这层设计逻辑，是一个实打实的亮点。
但必须要提醒一个最常见的翻车写法。很多人会在Java里先SELECT查remain_count，if判断大于0，再UPDATE。这是典型的"先查后改"超卖写法。两个请求同时查出remain_count等于1，都通过了if判断，然后都执行UPDATE，最终两个订单都插入成功，号源变成负数。这个坑几乎每个做挂号系统的人都会踩一次，务必避免。
4.4 取消预约与防重复取消
取消预约的正确姿势同样是事务加条件更新。第一步修改订单状态，第二步回补号源，两步放在同一个事务里。
sql复制UPDATE appointment
SET status = 3, cancel_time = NOW()
WHERE id = #{appointmentId} AND status IN (0, 1)
这样写有两个好处：一是带状态条件，订单已经不处于可取消状态时，更新影响行数为0，直接返回取消失败，天然防住重复取消；二是整个流程在事务里，订单状态修改成功但号源回补失败时全部回滚，不会出现"号没了钱也不退"的错乱。前端再配合按钮置灰做双重防护，这个场景的代码质量就接近工程标准了。
4.5 超时未确认订单的号源释放
如果设计了待支付状态，系统就要考虑"占号不付"的情况。我用Spring的@Scheduled定时任务，每半小时扫描一次待支付订单，超过15分钟未支付就自动取消并回补号源。
两个注意事项。第一，定时任务方法内不要做太重的逻辑，事务边界同样要标注清楚。第二，多实例部署时同一个定时任务会在多个节点上重复执行，要么引入分布式锁，要么在毕设阶段接受这个限制，并且在文档里主动说明这个隐患以及生产环境的解法。能把隐患和解决思路说清楚，评委反而会给你加分。
5. 医患交互：让系统从"挂号机"变成"服务平台"
5.1 在线咨询：不建议一上来就做WebSocket
一提医患交互，不少同学就想上WebSocket做实时聊天。技术本身没问题，但毕设时间就那么多，会话管理、心跳检测、离线消息、历史记录，每一项都是工作量，而且它们对最终评分的影响并不比一个完整的留言闭环大。
我的建议是做"留言—回复"模式。患者在医生详情页发起一条咨询留言，可以关联到某个历史预约；医生在医生端看到留言后进行回复，回复内容自动生成一条站内通知推送给患者。数据模型用一张consultation表，核心字段就是咨询内容、回复内容、回复时间。这是典型的工单式咨询。
为什么说这个设计更符合真实业务？医院场景中的医患线上沟通，大部分是非实时的"预约前咨询"和"就诊后随访"，患者留言往往不是等着秒回的。把这个业务逻辑讲清楚，比单纯讲"我用了WebSocket"专业得多。当然，如果主线做完时间充裕，在留言模型上加一个会话式详情页也完全可以。
5.2 消息通知：站内信足够撑起交互闭环
站内信系统只需要一张notification表：接收人、标题、内容、是否已读、创建时间。触发时机主要有：预约成功后给患者推送成功通知、诊前一天提醒患者按时就诊、医生回复留言后通知患者、订单取消后通知用户。
患者端在头部加一个消息图标，显示未读数，点击进入"我的消息"列表。这个功能虽然简单，但在演示时非常有节奏感：你在患者端走一遍"预约成功收到通知、医生回复收到通知"的完整链路，系统给人的整体体验立刻和"半成品管理系统"区别开来。
如果你还想增加一点工程感，可以定义一个SMSService接口，写一个模拟实现类，调用时只在日志里打印"向手机号xxx发送短信"。将来有真实短信服务商账号时再替换实现类，接口不用动。这种面向接口的设计体现出的是工程素养，比硬凑一个用不了的第三方接口强太多。
5.3 病历、评价与就诊闭环的收尾
医患交互还有一个容易被忽略的环节：就诊后的数据闭环。医生接诊时写病历，内容包括诊断结果、医嘱建议、处方说明，这些数据关联到对应的预约记录。患者端可以随时查看历史就诊记录和病历，就诊完成后还可以对医生进行评分和文字评价。
从代码上看，病历表和评价表的逻辑都很简单，但它们完成的是整个"预约—就诊—记录—评价"的闭环。演示时按这个顺序完整走一遍，评委就会觉得这个系统是自洽的，不是一个只管挂号的半成品。
6. 实测翻车清单：这些坑我替你先踩一遍
6.1 超卖现象和并发测试方法
本地开发时永远只有一个用户，并发问题往往不暴露。等你用两个浏览器窗口同时点提交，或者用JMeter压测时才发现订单多了一条，号源变成了负数。
做并发测试推荐用JMeter开20个线程，模拟20个用户同时抢同一排班的最后5个号。最终检验标准有两个：订单表插入的订单数不能超过5，排班表的remain_count必须等于0而不是负数。只要出现超卖或者负数，优先检查UPDATE语句是否带上了remain_count>0，然后再检查Service事务是否真正生效。
6.2 @Transactional失效的几种典型场景
Spring事务基于AOP代理实现，有几个场景会让事务静默失效。最常见的是同类内部调用：方法A在同一个类里调用方法B，B上面标的@Transactional不生效，因为调用走的是this调用而不是代理对象。解决办法是拆到不同类中注入调用，或者用AopContext获取代理。
另外两种情况也要注意：方法不是public时事务不生效；方法内部catch了异常并且没有抛出特定类型时，事务感知不到错误。排查方法不复杂，在Service里做一个小实验，抛出ArithmeticException看数据是否回滚，能回滚就说明事务正常。
6.3 前后端分离的跨域和预检请求
Vue跑在5173端口，SpringBoot跑在8080端口，浏览器一定会拦截跨域请求。解决办法是后端写一个MWebMvcConfigurer配置CORS，放行指定origin，允许携带凭证。
跨域问题还有个隐藏的坑是OPTIONS预检请求。当前端使用Authorization这类自定义请求头时，浏览器会先发一个OPTIONS请求探路。如果后端拦截器没有对OPTIONS直接放行，前端连token都送不出去。这个问题的排查过程很典型，我当时的解决路径是：先看浏览器Network发现请求停在Preflight，再到拦截器里加一行"如果是OPTIONS请求直接放行"，前后五分钟搞定，但不加这个判断可能让你怀疑人生两小时。
JWT的过期处理也要提前想清楚。把accessToken有效期设为1小时，前端统一在axios响应拦截器里遇到401时跳转登录页。有条件可以做refreshToken刷新机制，没条件就做"过期重新登录"，两种方案都要把逻辑理清楚。
6.4 时间格式、金额类型和魔法数字
LocalDateTime和前端字符串之间经常出现格式不一致。建议在Jackson全局配置里统一时间格式，比如yyyy-MM-dd HH:mm:ss，不要在每一个VO里手动转换，否则前端展示时东一个样式西一个样式。
金额字段用BigDecimal，不要用double。挂号费几十块钱看起来不会出精度问题，但八元挂号费减掉七角钱这种减法，double的精度误差就是会冒出来。在涉及钱的代码上，数据类型的规范使用是加分项。
状态值尽量避免散落魔法数字。预约状态0、1、2、3、4如果只在注释里写着含义，代码一旦重构就会出问题。用枚举类把含义固定住，是保证代码可读性最便宜的做法。另外，表名不要用order这种数据库保留字，预约订单表叫appointment比叫order省去无数引号问题。
7. 演示和答辩：项目做完，怎么讲成85分以上
7.1 演示顺序建议
很多人演示项目就是从登录开始噼里啪啦点一遍，讲完页面，时间到了，评委也没留下什么深刻印象。我更推荐"先讲业务、再走流程、最后亮技术"的三段式演示。
第一步，用一两页PPT配合一句话讲清业务背景和三种角色的闭环关系；第二步，走患者流程：注册登录、选择科室、查看医生排班、选时间段预约、模拟支付、查看我的预约、取消预约，完整走一遍；第三步，切换医生账号：查看排班、查看当日预约患者、写病历、回复留言；第四步，切换管理员账号：新增科室、发布排班、查看报表。最后再回来展示锁号SQL和事务边界，说明自己的技术亮点。
这套叙事的关键在于：你先把业务讲透，评委就会跟着你的思路走；最后亮出技术亮点时，说服力远大于一上来就讲代码架构。
7.2 高频答辩问题清单
结合我带项目的经验，下面这些问题被问到的概率非常高，提前准备好答案：
- 并发下多个患者同时抢最后一个号源怎么做？——讲清楚UPDATE带条件判断和事务，再补一句Redis预扣减方案。
- 为什么用JWT不用Session？——从无状态、适合前后端分离角度回答，并对比Session在分布式环境下的共享问题。
- 数据库如何保证数据完整性？——讲联合唯一索引、状态条件更新、事务回滚，不硬讲外键。
- 某医生排班被删除，已有预约怎么处理？——管理员删除排班必须做状态保护，有预约时只能停用，不能物理删除。
- 用户密码怎么存储？——BCrypt加密，绝不明文入库。
- 如果系统上线，单机部署行不行？——坦诚说明局限，再讲生产环境应有的负载均衡、Redis缓存和异步削峰思路。
回答问题的关键不在于每个知识点都完美，而在于表现出"我确实认真想过这些边界情况"。哪怕你说的是"生产上可以用消息队排队预约请求整形"，也比愣住强。
7.3 还有余力时，往上加的三个亮点
主线做完时间还有富余，按投入产出比排序，我会优先推荐三件事：一是把Redis锁号和热点缓存写好，技术硬核；二是用ECharts做一个预约数据统计大屏，视觉效果拉满；三是做完头像上传功能，完善医生照片和患者头像，功能完整度更接近真实系统。支付、短信、小程序这三件大工程则不建议碰，容易吃掉两周时间，而且多数学校并不会因此显著提分。
我在实际带项目的过程中越来越确定一件事：这类系统的分数差距，从来不是拼谁会更多框架，而是拼谁把核心业务做透了。一个能把"号源扣减、状态流转、并发控制"讲清楚的同学，哪怕界面朴素，也一定比一个页面花哨但业务说不明白的同学得分高。动手之前，先把表结构和状态机在纸上画明白，把锁号这一条主链路打通，剩下的所有事情都是添砖加瓦。对了，代码仓库里的README和数据库初始化脚本一定要写好，这份文件是你最后一份答辩材料，别等到答辩前一晚才开始补。