姬轩亦接到“乡镇医院挂号预约小程序”这类需求，第一反应是好事，说明基层医疗机构的信息化终于动起来了。但真做起来就会发现，它和市面上那些面向城市三甲医院的预约系统根本不是一回事：没有庞大的号源池、没有复杂的分级诊疗、甚至科室都可能不到十个，但业务链条一样不能少，而且对稳定性和可维护性的要求一点不含糊。
这个项目我按“Spring Boot后端 + 微信小程序前端 + 管理后台”三件套来做的，整套流程走完后攒了不少经验，今天把这套系统的设计思路、核心实现、还有那些文档里不会告诉你的坑，一次性梳理清楚。如果你正准备接类似的挂号预约项目，或者正在做相关毕业设计，这篇内容应该能帮你少走不少弯路。
1. 项目核心拆分：乡镇医院挂号预约到底要解决什么问题
1.1 需求场景与用户角色
乡镇医院的挂号场景和城市三甲有本质区别。三甲医院讲究多渠道分流、分时段精准预约、复杂专家排班；乡镇医院的需求更朴素——让镇上居民不用一大早跑来窗口排队，尤其是老人子女帮忙挂号、慢性病复诊开药这类高频场景。系统要服务好三类人群：普通患者（含帮家人挂号的年轻人）、医院号源管理科室、以及坐诊医生。
患者端要的功能很直接：选科室、选医生、选日期、看剩余号、提交预约、查记录、取消预约。管理端需要的是排班管理、号源发放、停诊处理、预约记录导出。医生端更轻，可能只需要看当天预约列表和标记到诊。整个系统的核心难点不在功能多，而在“号源不能超卖”和“停诊改约不能乱”这两件事上。
我把用户角色设计成三个端：微信小程序给患者用，Web管理后台给医院科室管理员用，医生端暂时复用管理后台的简单视图（不单独开发小程序，降低交付成本）。这个取舍在乡镇医院场景很务实——预算有限、使用人数少，多端并行反而增加培训和维护成本。
1.2 功能模块划分与技术选型逻辑
系统整体拆成三大块：预约核心链路、基础数据维护、通知与统计。预约核心链路包含科室/医生查询、号源查询、预约/取消预约、我的预约；基础数据维护包含科室管理、医生信息、排班计划、号源模板；通知与统计包含预约成功通知、停诊通知、预约取消提醒、以及每日预约统计报表。
后端框架用Spring Boot 2.7.x，原因后面会细说。小程序端不选原生开发而是用了uni-app，主要考虑医院后期可能有App端和H5端的扩展需求，一套代码多端复用对这类预算有限的项目很有吸引力。数据库用MySQL 8.0，缓存用Redis，ORM层面用MyBatis-Plus减少单表CRUD的重复劳动。
选型的核心逻辑是“常规但不陈旧”。Spring Boot已经是Java后端的绝对主流，招人和维护都容易；MyBatis-Plus在中小项目里比JPA更容易控制SQL，尤其在多表查询时更直观。前端选uni-app而不是微信原生语法，是因为医院项目普遍后续会要“再做个App吧”“做个公众号H5吧”这种需求，提前防一手比后面重构划算。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 后端设计与核心实现：Spring Boot的硬核部分
2.1 项目初始化与版本选型避坑
很多人一开始就踩进版本的坑，这里必须先展开讲。Spring Boot 3.x 已经出来很久了，但它基于 JDK 17，而很多医院的部署环境还停留在 JDK 8，或者运维只会装 Tomcat 8/9。如果选 Spring Boot 3.x，JDK 版本不符合，项目启动就是从头到尾的报错。所以这个项目我用的是 Spring Boot 2.7.18 + JDK 8，这也是目前国内中小型项目兼容性最稳的组合。
用 IDEA 创建项目时有几个细节值得注意：Spring Initializr 默认的 Server URL 可能连国外源很慢，建议把 Server URL 改成阿里云镜像。依赖选择上，只勾选 Spring Web、MyBatis Framework 和 MySQL Driver，Redis 和 Validation 可以在 pom.xml 里手动添加，这样创建速度更快，也不容易因为网络问题失败。
项目包结构我按功能模块划分而不是按技术层次划分，这是实际项目里很重要的一点：
code复制com.hospital.appointment
├── controller # 接口层，只处理请求参数和返回
├── service # 业务逻辑层
├── mapper # 数据访问层
├── entity # 数据库实体
├── dto # 数据传输对象
├── vo # 视图对象
├── config # 配置类（Redis、拦截器、WebMvc）
├── common # 公共类（统一返回、异常处理、工具类）
└── task # 定时任务
统一返回结果用 Result<T> 包装，包含 code、message、data 三