最近有个学弟抱着电脑来找我说他抽到的毕设题目是《医院挂号系统的设计与实现》项目包里还附带了一套源码和代码编号。他以为拿源码就能直接交差结果打开工程一看数据库脚本几十张表前端页面密密麻麻完全不知道该从哪里下手讲清楚“这个系统到底是怎么做出来的”。这个场景其实挺常见。医院挂号系统是毕业设计里头出现频率非常高的题目一方面它贴近真实业务流程清晰、角色明确适合用来展示对软件工程的理解另一方面它又藏在细节里——号源怎么分配、同一个人一秒钟内重复提交怎么办、退号之后号源怎么回到池子这些问题随便拎出一个都能在答辩现场追问出很多内容。这篇博文我就以这个项目为例从需求分析一直讲到前后端实现把我实际开发这类系统时会踩的坑、会做的取舍都摊开说一遍希望能帮你把题目吃透而不是只会粘一份能跑的代码。1. 需求拆解先搞清楚挂号系统里到底有几类人1.1 四个核心角色与他们的真实诉求很多人拿到题目第一反应是“挂号 选科室 选医生 选时间 提交订单”这个理解没有错但太粗了。一个能拿去答辩的挂号系统至少要覆盖四类角色患者前端用户主要想解决“排队难、跑空”的问题他关心的是能不能快速找到有号的医生、操作流程是否顺畅、挂错号能不能退。医生后台用户需要看到自己某一天有哪些病人预约、总共有多少号、还剩多少可加号的空间最好还能维护自己的出诊排班。前台/挂号员医院窗口操作员真正在医院场景里窗口挂号和APP挂号是并存的系统里应该支持代挂号、退号、退费这种操作。管理员系统管理员要维护科室、医生、排班规则查看每天的挂号统计、某个时段是否过载、用户账户状态是否异常。把这四类角色画成用例图整个系统的主线就出来了管理员维护基础资料医生设置排班患者根据排班完成预约前台处理线下挂号与退号。在开发之前先把这个用例图画清楚你后面写每个接口的时候才知道自己的代码属于哪条业务线。1.2 核心业务流程从选科室到完成就诊以患者端为例主流程可以拆成六步注册并登录账号选择就诊人或者维护就诊人信息按“科室 → 医生 → 出诊日期 → 号源时段”逐级筛选查看剩余号数点击“预约”确认就诊人信息、就诊时段、挂号费用提交订单生成挂号记录系统锁定对应号源就诊当天在线下报道就诊结束后记录归档。这里有两个容易被新手忽略的隐性流程退号流程和爽约流程。退号意味着对应的号源要加回号池爽约次数多了应该限制该用户的预约权限。如果你能在需求文档里主动写出这两个流程指导老师对你的评价会明显不一样——因为这说明你不是机械地做“增删改查”而是真的思考了业务闭环。1.3 非功能需求并发、数据一致和权限边界医院挂号系统跟一般进销存系统最大的区别在于短时高并发。早上放号那几分钟科室号源可能在几十秒内被抢完。这时候如果还在用“先查剩余号再插入纪录”的写法两个请求同时读到“还剩下1个号”就会出现超卖问题。所以需求阶段一定要把“同一号源只能被一个用户成功锁定”作为硬性约束。在实现上我推荐两种方案一种是数据库乐观锁在号源表上加版本号另一种是使用数据库行锁在更新号源状态时对主键行加锁。后面第4部分我会专门讲代码层面的做法。权限边界也是一个得分点管理员不能看到患者完整的身份证号医生只能看到自己排班下的预约列表患者只能看到自己的挂号记录。建议用Spring Security做一个简单的基于角色的权限控制虽然麻烦一点但答辩提到权限设计会非常加分。2. 技术选型Spring Boot Vue 这套组合是怎么定下来的2.1 选型逻辑既要能跑起来也要讲得清楚医院挂号系统在毕业设计里最常见的技术组合是Spring Boot MyBatis-Plus Vue MySQL我后来重新实现的时候也继续沿用了这套组合原因有三层学习曲线平缓Spring Boot自带内嵌Tomcat不需要单独部署服务器配置文件也简化了很多学生不需要花大量时间在环境搭建上前后端分离更好答辩Vue负责页面交互后端只提供JSON接口这符合目前企业里的主流开发方式答辩时你可以顺带提“前后端通过RESTful API通信”比传统的JSP写法更能体现工程化能力生态资料全MyBatis-Plus的代码生成器可以直接生成实体、Mapper、Service能节约大量重复的样板代码时间这部分省出来的时间值得用来打磨核心业务。如果你对Java不太熟也可以用Python Django或者Flask技术本身没有高下之分关键是你能把“为什么选它”讲得有理有据。我自己更倾向Java路线因为Spring生态在权限、事务、接口校验这些方面都有成熟的现成方案适合展示工程化能力。2.2 开发环境与工程目录结构开发现走的配置大致如下JDK 1.8或以上、Maven 3.6、MySQL 5.7/8.0、Vue CLI或Vite创建的前端工程。后端端口用8080前端开发服务器配8081通过Vite代理把/api开头的请求转发到后端避免联调时跨域问题。后端工程建议按功能模块分包而不是按技术层次分包。我的工程目录长这样com.hospital.registration ├── config // 全局配置CORS、拦截器、MyBatis配置 ├── controller // 接口层PatientController、DoctorController等 ├── service // 业务层挂号事务、排班生成、退号处理 ├── mapper // MyBatis的数据访问层 ├── entity // 数据库实体类 ├── dto // 前端交互对象例如预约提交DTO ├── common // 统一返回结果、异常处理、工具类 └── scheduler // 定时任务每日自动生成号源这种分包方式的好处是按业务看代码时不需要跨好几个层级去翻。答辩时线上演示调试追踪一个“退号”的完整链路也可以从controller一路点到service逻辑非常顺。3. 数据库设计号源、排班、挂号单三张核心表怎么建模3.1 核心表清单与相互关联数据库设计是毕业设计的重头戏因为有经验的老师上来就盯表和表之间的关系。挂号系统的核心表我认为至少有下面这些表名用途关键字段user用户表id, username, password, real_name, id_card, phonepatient就诊人表id, user_id, name, id_card, birthday, genderdepartment科室表id, dept_name, parent_id(支持两级科室树)doctor医生表id, dept_id, doctor_name, title, profileschedule排班表id, doctor_id, schedule_date, period, total_slots, remain_slots, versionregistration挂号单表id, patient_id, doctor_id, schedule_id, serial_no, status, create_timeoperation_log操作日志表id, user_id, action, detail, create_time排班表是连接“医生出诊计划”和“患者预约动作”的枢纽。我习惯把每个排班记录看成“一个医生在某个半天出的号池”里面直接维护total_slots和remain_slots。这样每次挂号只需要把remain_slots减一查询时直接用remain_slots判断是否还有号性能非常高。3.2 号源表要不要再拆细有些教科书上的设计会把号源拆成“具体到分钟”的号源明细表比如9:00-9:15一个号、9:15-9:30一个号这样拆的好处是能精确展示每个时间点剩下的号患者预约体验更像买电影票选座。缺点是表会膨胀每天每个医生要生成几十条号源记录逻辑上更加复杂。我建议毕业设计按“时间段号池”来做每天分上午和下午两个时段每个时段一个剩余数。如果采购觉得太简单可以再扩展一个visit_time_interval字段标记每个时段里的分钟粒度范围但底层的排班表仍然保持不用多子表这样开发量适中效果也很完整。答辩时我会主动说“这里我出于性能考虑做了聚合设计”老师不会觉得你偷懒反而觉得你权衡过。3.3 状态字段设计避免硬删除挂号单状态常见的有待就诊、已就诊、已退号、已爽约排班状态有未开始、进行中、已结束。所有主流程表的业务状态都建议用int类型存枚举值不要直接物理删除记录。比如退号应该把挂号单状态改成4然后把排班的remain_slots加回去而不是把挂号单删掉。保留历史记录对后续做统计很有用也会让数据库看起来更符合真实业务习惯。4. 后端逻辑排班生成、号源锁定与取消释放4.1 自动生成排班与号源初始化之前提到排班表是核心那么排班是怎么来的最简单的方式是定时任务自动生成未来7天的排班。管理员先给每个医生维护一份“周排班规则表”比如张三医生每周一上午出诊、周三下午出诊定时任务每天凌晨扫描规则为未来第7天生成排班记录。生成逻辑的核心代码大概是这样public void generateSchedules() { ListDoctorRule rules doctorRuleMapper.findEffectiveRules(); LocalDate targetDate LocalDate.now().plusDays(7); for (DoctorRule rule : rules) { // 只处理周一至周日与规则匹配的日期 if (rule.getWeekDay() ! targetDate.getDayOfWeek().getValue()) { continue; } Schedule schedule new Schedule(); schedule.setDoctorId(rule.getDoctorId()); schedule.setScheduleDate(targetDate); schedule.setPeriod(rule.getPeriod()); schedule.setTotalSlots(rule.getTotalSlots()); schedule.setRemainSlots(rule.getTotalSlots()); schedule.setVersion(0); schedule.setStatus(0); scheduleMapper.insert(schedule); } }这里有一个小坑如果定时任务执行到一半发生异常已经插入的一半排班会不会重复我在实际项目中会给doctor_id schedule_date period增加唯一索引生成前先检查是否已存在存在就跳过保证任务可以安全重复执行。4.2 挂号接口事务加乐观锁实现防超卖患者提交挂号请求时后端要做四件事校验患者信息、校验排班状态、扣减号源、生成挂号单。这个流程必须放在同一个事务里并且扣减号源要保证原子性。我最常用的防超卖写法是乐观锁更新SQL长这样Update(UPDATE schedule SET remain_slots remain_slots - 1, version version 1 WHERE id #{scheduleId} AND remain_slots 0 AND version #{version}) int deductSlot(Param(scheduleId) Long scheduleId, Param(version) Integer version);对应的Service逻辑可以这样组织Transactional(rollbackFor Exception.class) public Registration createRegistration(RegisterRequest request) { // 1. 查询排班信息 Schedule schedule scheduleMapper.selectById(request.getScheduleId()); if (schedule null || schedule.getStatus() ! 0) { throw new BusinessException(该排班已停止预约); } // 2. 尝试扣减号源 int rows scheduleMapper.deductSlot(request.getScheduleId(), schedule.getVersion()); if (rows 0) { throw new BusinessException(当前号源已被抢完请选择其他时段); } // 3. 生成挂号单 Registration reg new Registration(); reg.setPatientId(request.getPatientId()); reg.setScheduleId(request.getScheduleId()); reg.setSerialNo(generateSerialNo()); reg.setStatus(0); registrationMapper.insert(reg); return reg; }我对这个方案的理解是一次update操作里既判断了剩余号又做了版本校验更新行数为0就说明冲突或没号事务直接回滚不会出现两个请求都拿到同一个号的场景。对于毕设来说这个方案比自旋锁、Redis分布式锁更容易讲清楚还不会引入额外组件。4.3 退号接口与号源回补退号不只是把挂号单状态改掉它必须把号源还回去。有点绕的是并发问题患者A刚退号患者B就立刻刷新页面看到了一个余号并提交两个操作同时发生时怎么保证不超卖我做的处理是退号回补号源也用类似的方式Transactional(rollbackFor Exception.class) public void cancelRegistration(Long registrationId) { Registration reg registrationMapper.selectById(registrationId); if (reg null || reg.getStatus() ! 0) { throw new BusinessException(该挂号单当前不可退号); } // 更新挂号单状态为已退号 reg.setStatus(2); registrationMapper.updateById(reg); // 回补号源同样使用版本控制之外的无条件增加 scheduleMapper.refundSlot(reg.getScheduleId()); }refundSlot对应的SQL是remain_slots remain_slots 1不需要判断剩余数因为从数据一致性上看只有成功扣减过的号源才存在退号记录。这里要额外提醒一点退号规则里通常还有时间限制比如就诊当天不可退号这个约束我建议放在前端和后端各校验一次只做前端校验很容易被绕开。4.4 事务里容易忽略的几个点挂号这个业务虽然看起来简单但踩过的坑也不少我集中说三个尽量使用REQUIRED传播级别挂号涉及多个表的写入Spring默认的REQUIRED就可以让它们在同一个事务里完成不要画蛇添足给内部方法手动开多个事务。在事务中不要做远程耗时调用如果你在挂号事务里调用短信服务向用户发通知短信接口超时会导致整个事务回滚挂号也失败。正确的做法是挂号成功后把消息扔进队列表或者用异步线程发送。分布式环境下的幂等患者如果因为网络问题连续点了两次提交你的系统应该用同一个requestToken做幂等控制防止重复挂号。简单地给挂号单增加“患者排班状态”唯一索引也是一种兜底方案。5. 前端实现科室树、日历视图和倒计时锁单5.1 页面清单与路由规划前端我用Vue 3 Element Plus。页面不算多但每个页面背后都有交互逻辑要理顺首页展示热门科室、医院公告、当日停诊信息科室列表页左侧科室树、右侧医生列表支持按科室名称搜索医生排班页展示某个医生接下来7天的出诊安排可选择上午/下午时段确认预约页展示就诊人、就诊时间、费用提交时需要勾选“已阅读就诊须知”个人中心我的预约列表、退号入口、就诊历史后台管理页排班管理、预约记录查询、统计看板。如果时间紧张你可以先做“首页 科室列表 医生排班 个人中心”四个核心页面后台管理用一套简单的表格页面展示也完全能支撑答辩演示。5.2 选择链路的关键交互日历与号池联动医生排班页是整个前端交互最复杂的部分核心是一个7天横向日历每天显示上午、下午两个时段同时显示“剩余号数”。用户选中某个时段后如果remain_slots 0按钮显示“可预约”如果为0按钮置灰。这里的数据建议一次接口查回来不要让用户每点一天就重新拉一次接口体验不好{ doctorId: 10, date: 2025-03-20, periods: [ { period: 1, total: 30, remain: 12, status: 0 }, { period: 2, total: 20, remain: 0, status: 1 } ] }选中可预约时段的按钮后前端跳转到确认页。我在确认页做了一个“倒计时锁单”效果提交前先调一个“预占号源”接口把号源预占10分钟前端显示倒计时超时后释放。这样一方面防止用户犹犹豫豫导致号被抢另一方面也让前端交互显得更有真实感。虽然毕设不一定要做到这一步但做出来以后演示效果很加分。5.3 前端与后端的状态一致性按钮不可信曾经见过同学的前端实现是这样的点击预约前先查一次remain_slots大于0就显示可约然后直接提交。这种做法在单用户操作下没什么问题但实际并发下用户看到的“还有1个号”很可能在点击瞬间就被别人抢走了。所以我在前端所有“可预约”按钮的判断后段都还是以后端接口最终的返回结果为准前端只是展示一个尽量接近实时的剩余数。如果后端返回“已被抢完”前端要弹出友好提示并自动刷新该医生的排班数据。6. 答辩环节这套系统最容易被追问的几个深水区问题6.1 并发超卖你怎么解决的这是我认为最高频的提问。回答思路要清晰先说问题本质再说方案最后说为什么不用其他方案。比如可以这样组织语言“挂号系统的核心风险是号源多扣。我在排班表里设计了一个version字段扣减号源时使用乐观锁更新如果更新行数为0说明该条记录已经被其他事务修改本次请求直接失败回滚。相比悲观锁乐观锁在读操作多的场景下开销更小相比Redis分布式锁它不需要引入额外中间件更适合课程设计这种体量的系统。”6.2 如果同一时刻大量用户抢同一个医生怎么办这个问题其实是上一个的延伸。你可以在排班表上再加一个多行缓冲把每个时段的号源拆成多个子队列比如每个医生每时段分成5个小号池每个小号池200个号用户请求后随机路由到某个小号池减少同一行的竞争。回答的时候点到为止说明这是一个优化思路毕设中不一定要实现。6.3 如何保证退号后号源不丢失回答思路是“交易状态流转和号源回补放在同一个事务里”。你建一个operation_log表记录每次退号操作同时在排班表上执行remain_slots 1两者要么同时成功、要么同时失败不会出现挂号单已退但号源没回来的中间状态。6.4 你的系统扩展性体现在哪里可以提三个方向一是把排班规则抽成独立表支持不同医生不同周规则二是把号源从聚合设计扩展成分钟级明细以应对更精细的预约需求三是预留支付模块接口后续可以接入在线支付或医保实时结算。不要说得太大要落到自己的表结构和接口设计上。6.5 为什么不用Redis做分布式锁我一般会如实回答毕设场景下MySQL乐观锁已经满足需求引入Redis还需要额外安装和配置环境增加系统复杂度但如果访问量达到上万级别Redis预减库存可以降低数据库压力。最后加一句“如果生产环境需要可以考虑用Redisson实现”就可以展示你了解进阶方案。我在实际开发项目时最深刻的体会是这类毕业设计题目拼的不是功能数量而是逻辑严谨性和对异常场景的处理能力。很多同学交上来的代码能跑通“挂号成功”这一条路但退号、复诊、停诊、超卖、权限越权这些角落基本是空的。你哪怕只把挂号防超卖和退号回补这两块从数据模型到接口到前端完整做通再带着事务日志上线答辩表现就已经超过大部分人了。剩下就是好好把源码里的每一层读熟别让老师问到一个细节你自己还没翻到那一页。