做了这么多年开发每年到这个时间点总有学弟学妹来问毕设选题的事。今年被问到最多的一项就是“基于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或若依框架快速搭建。后台需要的功能也对应着用户的路径科室管理负责增删改科室医生管理负责维护医生信息并绑定科室排班管理是核心管理员选择某医生、日期、午别、总号数后生成排班系统会自动按号源序号展开生成号源记录订单管理用于查看用户预约明细和退号结果公告管理负
