医院预约挂号小程序源码解析：号源状态机与并发扣减设计

简介这份资源是面向计算机专业毕业设计学生与Java初学者的一套微信小程序医院预约挂号系统配套文档围绕线上挂号这一典型场景梳理了从需求背景到技术落地的完整思路可帮助读者理解如何用小程序解决传统窗口排队挂号的效率问题。压缩包内共1个docx文件约883KB内容涵盖项目背景与意义、微信小程序与Java、Spring Boot、SSM、MySQL的技术选型分析以及系统架构、用户管理、医生管理、预约管理、通知提醒等关键模块设计与数据安全、高并发、稳定性等挑战的应对方案并附有摘要与目录便于按章节查阅和整理成文。目前已有382人学习适合需要参考选题结构、撰写开题报告或搭建同类挂号系统的读者使用。1. 预约挂号小程序为什么“先到先得”的号源反而最考验后端设计医院挂号窗口前那条长队本质上是把“号源分配”这件事交给了物理空间来仲裁——谁先站到窗口谁就先拿到号。搬到微信小程序里之后这条队伍消失了但问题并没有消失只是从“排队顺序”变成了“并发请求谁先落库”。很多人第一次看这类源码会觉得不就是几张表加几个增删改查真正翻车的地方恰恰在于号源是有状态的稀缺资源而小程序端用户会在放号瞬间集中点击。这份医院预约挂号小程序源码把科室浏览、医生详情、在线预约、后台审核串成了一条完整链路值得搞懂的不是页面怎么画而是号源从“可预约”变成“已占用”的那几百毫秒里系统到底做了什么。理解了这一层你再看任何预约类系统都能一眼看出它的并发模型站在哪一边。2. 号源状态机一次预约到底改了几张表2.1 从“看到有号”到“占住号”不是一步小程序端用户点进医生详情页看到“今日剩余 3 个号”这个数字来自一次查询用户点“立即预约”提交的是一次写操作。查询和写入之间隔着用户的思考时间也隔着网络往返。如果系统把“剩余号数”当成一个可以随便读的普通字段那么两个用户同时读到 3各自减 1最终可能卖出 4 个号。这类系统的核心不是“能不能存下预约记录”而是“号源扣减是否具备原子性”。常见的实现思路是把号源抽象成一条有状态的记录而不是一个纯计数器。医生排班表里一行代表“某医生某天某时段”它带一个总号数和一个已用号数预约动作本质上是对这一行做条件更新只有当已用号数小于总号数时才允许加一。这个条件必须和更新在同一条 SQL 里完成不能先查后改。-- 号源扣减条件与更新合并为一条语句避免先查后改的竞态 UPDATE doctor_schedule SET used_count used_count 1 WHERE schedule_id #{scheduleId} AND used_count total_count; -- 受影响行数为 0 表示号已放完业务层据此返回“号源不足”这段 SQL 的关键在WHERE里的used_count total_count。数据库在执行更新时会持有行锁两个并发请求到达时第二个请求要么等待第一个提交后重新判断条件要么直接看到条件不成立而影响 0 行。参数scheduleId定位到具体排班total_count是放号上限used_count是已占用数。业务层拿到受影响行数后决定成功还是失败而不是再查一次数据库来判断——再查一次就又回到了竞态窗口里。2.2 预约记录与号源扣减的顺序问题号源扣减成功之后才插入预约记录这个顺序不能反。如果先插预约记录再扣号源扣减失败时就得回滚或删除刚插入的记录多一次写操作也多一个失败点。正确顺序是条件更新号源 → 受影响行数为 1 → 插入预约记录 → 两者放在同一个事务里。事务边界要覆盖这两步否则号扣了、记录没插进去号就凭空消失了。// 事务内完成扣号源 写预约记录任一步失败整体回滚 Transactional(rollbackFor Exception.class) public Result? book(BookingRequest req) { int affected scheduleMapper.deduct(req.getScheduleId()); if (affected 0) { return Result.fail(号源不足); // 条件更新未命中直接返回 } bookingMapper.insert(buildBooking(req)); // 号源已占落预约记录 return Result.ok(); }Transactional保证扣减和插入同生共死rollbackFor Exception.class让受检异常也触发回滚。这里有个容易被忽略的点如果号源扣减成功但插入预约记录时抛了唯一键冲突比如同一用户重复提交事务回滚会把号源加回去这是对的但如果业务上允许同一用户多挂不同科室唯一键就不能简单设在用户维度上否则正常预约会被误杀。2.3 号源状态在表结构里怎么体现从源码的数据库设计看核心表围绕用户、患者、科室、医生、排班、预约几条线展开。排班表承担号源状态预约表承担占用凭证两者通过排班 ID 关联。这种拆法的好处是号源是“可售库存”预约是“成交记录”库存和成交分离后台审核只需要改预约记录的状态不影响库存本身取消预约时再把库存加回去形成闭环。表承担职责与号源的关系排班表某医生某时段的总号数与已用号数号源状态的唯一权威来源预约表一次占用的凭证与审核状态引用排班 ID不重复存号数医生表医生基本信息与所属科室排班的外键来源科室表科室分类医生归属的上级维度把“剩余号数”做成排班表上的一个派生值总号数减已用号数而不是单独维护一个剩余字段是为了避免两个字段不同步。派生值永远只有一个写入点出错面小得多。3. 小程序端与后端的分工为什么查询可以随便读写入必须收口3.1 科室与医生列表是典型的读多写少小程序端打开首页先看科室再点科室看医生再点医生看排班。这条链路上每一步都是查询而且同一批数据会被大量用户反复读取。这类读操作不需要事务也不需要加锁直接走普通查询即可。源码里科室查看界面的左侧科室列表、右侧医生列表本质上就是两条按科室 ID 关联的查询。-- 按科室查医生读操作不加锁走普通索引即可 SELECT d.doctor_id, d.doctor_name, d.title, d.specialty FROM doctor d WHERE d.dept_id #{deptId} AND d.status 1 ORDER BY d.title_level DESC;status 1过滤掉停诊医生title_level控制职称排序让主任医师排在前面。这类查询的优化点在索引dept_id上要有索引否则科室一多就是全表扫描。读多写少的场景下缓存是常见补充手段但缓存带来的问题是号源数字可能滞后——所以缓存只适合放在科室、医生这类静态信息上排班的剩余号数不适合长时间缓存否则用户看到有号、点进去却没号体验比直接显示没号更差。3.2 写入收口到后端接口小程序端不直接碰数据库所有写操作都通过后端接口。这不是为了“架构好看”而是因为写操作需要统一的校验、事务和权限判断。预约接口进来后后端要做的事至少包括校验用户是否登录、校验排班是否存在且未过期、执行条件扣减、写预约记录、返回结果。这些逻辑放在小程序端做不了也不该做。后端用 Spring Boot 暴露 RESTful 接口小程序端用wx.request调用。接口的入参只传排班 ID 和必要的用户标识不传“剩余号数”这类客户端可伪造的字段——号源判断必须在服务端基于数据库当前值完成。这是这类系统最基本的安全边界客户端传来的任何数字都不可信。3.3 个人中心与预约记录的归属校验个人中心里能看到“我的预约”这个查询必须带用户维度过滤。常见翻车是接口只按预约 ID 查详情没校验这条预约是否属于当前用户导致改一个 ID 就能看到别人的挂号信息。正确做法是查询条件里同时带用户标识和预约 ID或者先查归属再返回。-- 我的预约用户维度必须进 WHERE不能只在应用层判断 SELECT b.booking_id, b.schedule_id, b.status, s.visit_date FROM booking b JOIN doctor_schedule s ON b.schedule_id s.schedule_id WHERE b.user_id #{userId} ORDER BY b.create_time DESC;user_id进WHERE而不是查出来再比对是为了让数据库层面就完成隔离减少应用层漏判的可能。这类细节在源码里往往不起眼但它是“能不能上线”和“上线会不会出事”的分界线。4. 后台管理审核动作如何反向影响号源4.1 预约审核不是纯状态字段后台管理员看到待审核的预约点“通过”或“驳回”。如果只改预约表的状态字段号源不受影响那驳回之后这个号就永远被占着库存只减不增。所以审核动作要和号源联动驳回时把排班的已用号数减一通过时不动。这个联动同样要放在事务里并且减号源时要做下界保护防止减成负数。-- 驳回预约状态置为驳回同时归还号源used_count 不低于 0 UPDATE doctor_schedule SET used_count used_count - 1 WHERE schedule_id #{scheduleId} AND used_count 0;used_count 0是防御性条件正常流程下不会触发但一旦出现重复驳回或数据不一致它能防止库存被减穿。后台的医生信息管理、科室管理则是纯配置类操作新增改查不涉及号源和预约审核要分开看待——把两类操作混在一个事务里只会让锁的范围无谓变大。4.2 管理员权限是单点还是多点源码的系统分析部分提到管理员具有整体管理权限包括医生、科室、病患、挂号、系统管理。这种单角色设计在毕设类系统里很常见实现简单但意味着一个账号能做所有事。从机制上看权限判断应该收口在一个拦截器或过滤器里而不是每个接口里手写 if。常见实现是登录后发一个令牌拦截器校验令牌并解析角色接口只关心业务。这种设计的取舍在于单角色省掉了权限表、角色表、关联表三张表开发快代价是无法做细粒度授权比如“只让某个人审核挂号但不能改医生信息”就做不到。如果后续要扩展最小改动是把角色字段从枚举改成角色表拦截器逻辑不变。4.3 公告与反馈低频写入的旁路公告发布和意见反馈属于低频写入和号源主链路没有强关联。它们的价值在于形成闭环用户在小程序端提交反馈后台能看到并回应。这类功能在实现上不需要复杂事务单条插入即可但要注意反馈内容的长度限制和转义避免把用户输入原样拼进页面导致脚本注入。参数校验在前端做一遍是体验在后端再做一遍是底线。5. 避坑与排查这类系统最容易翻车的几个点5.1 号源超卖现象是预约数大于放号数现象后台统计某排班的预约记录数超过了总号数或者用户投诉“明明显示有号却约不上”。原因通常是先查后改代码里先SELECT剩余号数判断大于 0再UPDATE减一两个请求在查询和更新之间交错。解决是把判断条件写进UPDATE的WHERE里用受影响行数判断成败并且扣减和写预约记录放在同一事务。5.2 重复提交现象是同一用户同一时段两条预约现象用户手抖连点两次或者网络慢导致前端重复发请求数据库里出现两条相同预约。原因是没有幂等控制。解决有两个层次前端按钮点击后置灰是体验层后端在预约表上对“用户 排班”建唯一索引是数据层。唯一索引冲突时捕获异常并返回“请勿重复预约”同时事务回滚会把号源加回去不会造成库存泄漏。5.3 取消预约后号没回来现象是库存只减不增现象用户取消预约成功但该时段剩余号数没有恢复。原因是取消逻辑只改了预约状态忘了归还号源或者归还时没做下界保护导致异常回滚。解决是把“改状态 归还号源”放进同一事务归还语句带used_count 0条件并在测试用例里专门覆盖“预约→取消→再预约”这条路径。5.4 时间边界现象是过期排班仍可预约现象用户能约到昨天的号或者约到已经过了就诊时间的时段。原因是预约接口只校验了号源数量没校验排班时间。解决是在扣减之前先查排班判断visit_date和时段是否在当前时间之后过期直接拒绝。这个校验要放在服务端不能依赖小程序端隐藏按钮——接口是可以被直接调用的。5.5 数据库连接与字符集现象是中文医生名乱码或连接超时现象后台录入的医生姓名在小程序端显示为问号或者并发稍高就报连接超时。原因是建库时字符集没统一成 utf8mb4以及连接池上限设得过小。解决是建库建表统一字符集连接池按预期并发量配置并设置合理的超时时间。这类问题不涉及业务逻辑但排查起来很费时间血泪经验是环境初始化脚本里就把字符集写死。6. 设计取舍为什么这类系统宁可“笨”一点看完号源扣减、事务边界和审核联动会发现这套设计里没有多少“聪明”的技巧没有分布式锁没有消息队列削峰没有复杂的缓存一致性方案。这不是因为想不到而是因为在这个规模下简单方案的正确性更容易保证。一条带条件的UPDATE加一个本地事务已经把超卖问题解决在数据库层面引入分布式锁反而要多维护一个中间件锁的超时、续期、释放都是新的故障点。技术选型的第一原则是匹配规模不是匹配时髦。另一个取舍在数据模型上号源状态放在排班表预约记录单独一张表两者用外键关联而不是把号数冗余到预约表里。冗余能减少一次关联查询但会带来两个写入点一旦某条路径漏更新就出现数据不一致。宁可多一次 join也不留两个真相来源——这是我在看这类源码时最看重的一点。判断一份预约系统源码值不值得深挖不看页面多漂亮看它扣号源的那条 SQL 有没有把条件写进WHERE看它的事务边界有没有覆盖扣减和落单两步。还有一个容易被低估的点是“失败路径”的完整性号源不足怎么返回、重复提交怎么处理、取消后怎么归还、过期怎么拦截。这些路径在正常演示里走不到但线上一定会遇到。源码里如果这些分支都有对应处理说明作者是真跑过流程的。从那以后我每次看预约类项目都会先把这几条失败路径在脑子里过一遍再去读主流程——顺序反过来很容易被表面的功能列表带偏。希望帮到你。本文还有配套的精品资源点击获取