千里江山寒色远1. 这个项目的定位：为什么医院需要一套微信小程序综合服务平台
先说说我最初接手这个项目时的判断。题目里写的是“基于微信小程序的医院综合服务平台”，关键词落在微信小程序和 SSM 上，和市面上那些堆砌功能、做完就扔的毕设不同，这个题目其实有一个非常明确的业务锚点：医院场景下的患者服务流程重构。很多同学把这个题目做成一个单纯的“预约挂号系统”，说实话，那太浪费了。医院综合服务平台的本质，不是把线下窗口搬到线上，而是围绕患者从“我需要看病”到“我看完病”的完整链路，把挂号、报到、缴费、查报告、看医生排班这些高频动作统一收纳进一个小程序里。
先讲一个我在设计前期反复确认的问题：这个平台到底覆盖哪些角色。表面上看，患者是小程序端的主要使用者，但医院综合服务平台真正能跑起来，离不开两个隐藏角色——医生端和管理后台。医生端负责排班管理、号源维护、看诊状态更新；管理后台负责科室、医生、公告、预约记录、支付流水这些核心数据的维护。所以架构上我一开始就确定了三个端：微信小程序端（患者使用）、Web 管理端（医院管理员和医生使用）、后端服务（SSM 框架统一提供接口）。三端共用同一个数据库和同一套接口服务，这种结构看起来简单，但扩展性是最好的，后续要加一个护士端或者大屏展示，只需要复用接口，不牵扯底层改动。
适合谁参考这篇内容呢？第一类是正在做类似毕设选题的同学，尤其是题目里带“微信小程序 + SSM”组合的，你大概率会碰到和我一样的问题——不是不知道怎么写代码，而是不知道业务边界画在哪里、表怎么设计才不用返工。第二类是想把毕设真正做成“能演示、能上线、经得起问”的工程的同学，我会把很多答辩和演示时容易被追问的细节一并展开。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 技术选型的底层逻辑：微信小程序加 SSM 到底够不够用
2.1 前端为什么选微信小程序而不是 H5 或原生 App
这个问题的答案，做项目之前我不太服气，做完之后我是真服气了。医院这个场景有几个天然属性：用户是“偶尔用但必须即用即走”的大众群体，不会为了挂个号专门下载一个 App；H5 虽然也不用下载，但入口在微信浏览器里，入口深、消息触达弱、登录态不稳定，而且调起微信支付、获取手机号这类能力的时候，H5 的体验天然弱于小程序。微信小程序的“扫一扫即用、悬浮窗回退、订阅消息通知”这些能力，恰好击中医院预约这类低频但强时效的场景。患者挂了号，医生停诊了，你需要能主动通知他，小程序订阅消息能扛这个活，H5 很难做到同等体验。
从开发角度看，小程序也有它的坑，比如包体积限制（主包不能超过 2MB）、自定义组件生态不如 Vue 完整、部分 API 在安卓和 iOS 上行为不一致。但这些问题都有成熟解法：分包加载、用 WeUI 组件库、兼容判断。比起原生 App 的双端开发和审核成本，小程序的性价比高太多了。所以结论很明确：面向大众、低频、强场景的医疗服务，微信小程序是最合理的载体。
2.2 后端为什么选 SSM 而不是 Spring Boot
这一点可能是很多人的疑问。2024 年了，Spring Boot 都出 3.x 了，为什么还用 SSM？我的理解是，这个选择要看你做这个项目的目标是什么。如果目标是生产级落地、快速迭代，那 Spring Boot 当然更好，内嵌容器、自动配置、起步依赖能省掉大量配置时间。但如果你是在做一个教学性质浓厚、需要把 Spring、SpringMVC、MyBatis 三层框架的协作关系完整跑通的项目，SSM 反而是一个更好的“教材”——它让你必须手动维护 applicationContext.xml、spring-mvc.xml、mybatis-config.xml，必须理解 SqlMapConfig 和 Mapper 接口是如何绑定在一起的，必须手工处理事务切面的配置。这些知识在 Spring Boot 里被“约定大于配置”隐藏了，但面试的时候、答辩的时候，老师最常问的恰恰就是这些底层问题。
我当时做这个项目，被问的第一个问题就是：“为什么不用 Spring Boot？”我当时的回答是：SSM 是经典的企业级组合，我选择它是因为能更清晰地控制事务边界和 SQL 映射逻辑，且项目对部署环境要求更轻（外置 Tomcat 即可），不依赖内嵌容器。这个回答其实挺讨巧的，既承认了 SSM 的“传统”，又表达了自己对原理的掌握。而且从实际代码量来看，SSM 配置写完之后，业务开发和 Spring Boot 几乎没有差别，重点还是在业务逻辑和 SQL 上。
2.3 前后端通信的数据契约设计
这个点容易被忽略，但我觉得是整个项目能否顺畅开发的命门。小程序端和后端是分离的两个工程，双方之间只能通过 HTTP 接口通信，那接口返回的数据结构就必须在一开始定清楚，不然后端给的是 {code:0, data:{}}，前端等的是 {status:200, result:[]}，联调的时候光是改字段就够你喝一壶。
我设计的统一返回结构是这样的：
json复制{
"code": 200,
"msg": "操作成功",
"data": {}
}
约定 code=200 表示成功，code=500 表示服务端异常，code=401 表示未登录或 token 失效。所有接口的返回都要走这个壳。小程序端的 request 封装里统一判断 code，非 200 直接弹 toast，不用每个页面重复写错误处理。这个约定一旦定下来，前后端可以完全并行开发，我甚至通过 Mock 数据先把小程序页面都写完，再等后端接口就绪后一键切换 baseUrl。项目文档里我专门写了一节“接口约定”，这部分在答辩时也很有加分效果，因为它体现的是工程思维，不只是会调 API。
3. 系统功能模块拆解：从患者预约到医生看诊的全链路
3.1 患者端的核心功能怎么划分
患者端是微信小程序的主体，我梳理功能时没有按“我要做什么”来排列，而是按“患者到医院之后会经历什么”来设计。这样设计出来的页面结构和用户心智是吻合的。整个患者流程我拆成了五段：查医生、约时间、到医院、看结果、付费用。对应到小程序端就是五个功能模块：
- 首页：医院公告、科室入口、快捷功能按钮（预约挂号、报告查询、门诊缴费、个人中心）
- 科室与医生列表：按科室维度浏览，点击科室看医生列表，医生卡片上展示职称、擅长领域、剩余号源
- 预约挂号：选择医生、选择日期、查看排班时段、确认号源、提交预约
- 报告查询：按时间范围查询检查/检验报告，支持查看报告详情，包括指标数值和