做了这么多年开发，每年到这个时间点，总有学弟学妹来问毕设选题的事。今年被问到最多的一项，就是“基于SpringBoot+小程序的掌上智慧医疗系统”也就是医院预约挂号系统这个方向。说实话，这个选题在往年毕业设计里属于“常青树”级别，但常青不代表平庸。恰恰相反，它踩中了当下医院信息化和移动就医的刚需场景，技术栈又非常主流，SpringBoot加小程序加MySQL的组合，既能体现后端业务设计能力，又能展示完整的前端交互闭环，工作量、难度、答辩可讲点都恰到好处。这篇文章就把这套系统的核心思路、技术拆解、实战细节和避坑经验一次性说透，想选这个题或者已经在做这个题的同学，这算是给你的参考底稿。
1. 为什么医疗预约挂号是毕设的“安全牌”兼“出彩牌”
选题这件事，第一原则不是追求新奇，而是“能做完、能讲清、能通过”。医疗预约挂号系统在这三点上几乎完美契合。
很多人一听“医疗”就觉得复杂，实际上预约挂号只是医疗信息化里的一个垂直子场景，业务边界非常清晰：用户浏览科室和医生、查看排班、选择号源、提交预约、支付费用、查看订单，后台管理员维护科室、医生、排班信息，仅此而已。流程不长，但足够撑起一套完整的前后端项目。相比做电商、做社交这类动辄要处理复杂推荐算法或IM长连接的题目，预约挂号的核心流程更适合本科阶段的技术水平，只要把CRUD做扎实、把关键业务规则想明白，答辩时就有底气。
从就业角度看，SpringBoot在国内后台岗位的占有率不用多说，小程序又已经是微信生态里最轻量级的C端应用形态。一套题目同时覆盖两种主流技术，放在简历里本身就是加分项。而且如果你将来打算往医疗信息化方向走，预约挂号的业务模型和真实医院系统几乎一致，提前接触一次，以后面试聊业务场景时你会比别人多很多话说。
我当时给A同学指导这套系统时，他第一反应也是“这题是不是太老了”。我给他的建议是：题目老没关系，关键是你在老题目里能不能做出新细节。哪怕都是预约挂号，你对号源锁定的设计、对并发场景的思考、对退号释放机制的实现，决定了它是及格分还是优秀分。
2. 技术选型和总体架构的取舍逻辑
2.1 SpringBoot 与小程序端技术选型方案
这套系统的标准技术方案是：SpringBoot负责后端接口，微信小程序负责C端用户界面，MySQL存储业务数据。当然“SpringBoot加小程序”里也分很多细节，不同选择对应不同的开发效率和答辩难度。
后端如果选SpringBoot 2.x配合MyBatis-Plus，你会发现写单表CRUD非常省力，MyBatis-Plus的条件构造器和分页插件能减少大量重复代码。也有不少项目直接用Spring Data JPA，特点是实体映射方便，但多表联查时的灵活性不如MyBatis强。我个人更推荐MyBatis-Plus，因为毕设场景下业务表之间的关联逻辑并不复杂，MP的LambdaQueryWrapper配合ServiceImpl的封装已经把80%的增删改查做完了，剩下就是写业务。
权限认证这里，虽然Spring Security是标准答案，但用在毕设里稍显笨重。主流做法是用JWT做无状态鉴权，小程序端登录后拿到token，之后每次请求在请求头里带token，后端用拦截器统一解析用户身份。这么做省去了Session管理，也符合现在前后端分离的主流思路，答辩时还能讲清楚token刷新的机制，被认为有生产级意识。
小程序端目前最省事的做法是用原生语言加Vant Weapp组件库。Vant Weapp对表单、弹窗、日历的选择都有现成组件，预约挂号里最关键的“选择日期看排班”场景，用一个日历组件加一个列表组件就能完成，视觉上也不显廉价。如果你不想花时间在样式上，这个组合效率非常高。
2.2 单体重构还是微服务拆解
另外一个常见问题是：要不要上微服务。我强烈建议不要。
毕设的核心目标是展示你对业务和主流技术的掌握，而微服务带来的服务注册、配置中心、网关这些复杂度，在预约挂号这个体量下属于画蛇添足。你需要的不是让评委觉得“技术多”，而是让评委觉得“解决问题的方式合理”。单体会话模型下，用SpringBoot模块化拆分出controller、service、mapper这几层，任何有经验的老师都能一眼看出你掌握了分层架构的核心逻辑。
服务间的内部调用全走本地方法，事务管理只需要@Transactional注解，分布式的难题一个都不碰。这样做出来的项目演示稳定性更高，写文档也更省心。
2.3 表结构设计的核心套路
预约挂号系统的核心表我建议控制在7张左右：用户表、科室表、医生表、排班表、号源表、预约订单表、支付流水表。再多就容易显得堆砌，再少就会让业务展示力不足。
科室表和医生表是一对多关系，这里有个小技巧：科室表里直接存一个sort字段做排序，挂号页面的科室列表就可以按这个字段控制顺序。医生表存的是医生姓名、职称、简介、头像URL、所属科室ID和排班数量。头像不用真传文件，存个外链字符串即可，省去文件上传这一整块逻辑。
排班和号源是这套系统的设计核心，我单独展开讲。排班表存医生ID、排班日期、午别（上午还是下午）、开始时间、结束时间、总号数。号源表是排班表的展开，存排班ID、号源序号、就诊时间段和当前状态。为什么要把号源单独拆一张表？因为预约的实际粒度是“某个医生在某个上午的第3个号”，拆开后每次预约就是锁定某一行号源，非常清晰。如果在排班表上直接存一个剩余号数递减，并发场景下很容易超卖，而且无法实现“具体选哪个时段”的交互体验。
3. 业务模块拆解与核心流程实现
3.1 用户端核心模块与页面流转
用户端小程序涉及的页面包括首页、科室列表、医生列表、医生详情、排班日历、确认订单、支付页、订单列表、订单详情和个人中心。页面看起来多，但每条路径都是围绕“找医生”和“约时间”这两件事展开的。
首页这块我没有做成花哨的广告轮播，而是直接放一个科室导航宫格加一个搜索框。科室导航宫格的好处是用户点一下就进入对应科室的医生列表，路径最短。搜索框支持按医生姓名模糊搜索，这在用户明确要挂某个专家的号时非常有用。
用户点进医生详情页后，最核心的组件是排班日历。你需要在小程序端调用微信的日历选择能力，或者引入Vant的Calendar组件，默认禁用过去的日期，用户选定日期后再拉取当天的排班列表和剩余号源。这个交互有一个关键的体验细节：如果某个排班已经没号了，界面上要明确显示“约满”而不是还能点进去再提示失败，减少无效操作。
确认订单页要展示的信息包括患者姓名、手机号、就诊人类型（自费还是医保）、所选医生、科室、日期、时段、号序和挂号费。这里必须支持新增就诊人档案，也就是姓名、身份证号、手机号这套信息，下单时从档案里选。新增就诊人的逻辑虽然简单，但能有“电子健康档案”的展示效果，系统整体厚度一下就上来了。
提交订单后就是支付环节。我这里推荐走微信支付的模拟支付，不需要真接支付网关。你只要在支付接口里生成一条支付流水单，把状态置为已支付即可。如果导师要求更完整，可以对接微信支付的统一下单API，但个人号没有商户资质时无法走通，建议在文档里说明模拟支付的实现思路，把真实支付接口的接入方案写清楚即可。答辩时诚实说清楚哪些是模拟，哪些是真实能力，反而比包装过度更可信。
3.2 管理后台的功能划分
管理后台并不一定需要单独做一套Web页面，但至少要提供一个H5管理端或者复用模拟数据接口。如果是走前后端分离的后台管理界面，可以选用Vue加Element UI或若依框架快速搭建。后台需要的功能也对应着用户的路径：科室管理负责增删改科室；医生管理负责维护医生信息并绑定科室；排班管理是核心，管理员选择某医生、日期、午别、总号数后生成排班，系统会自动按号源序号展开生成号源记录；订单管理用于查看用户预约明细和退号结果；公告管理负
