孤之背影医务室信息化这件事，很多学校其实一直处于“半吊子”状态。挂号靠纸质登记本，药物管理靠人工盘库，健康档案靠一摞摞体检表。真遇到流感季或者运动会外伤高峰，医务室里常常挤成一团，校医老师一边量体温一边还要腾手翻台账。所以我当时把毕业设计题目定为“校园医务室健康服务与智能管理系统”——springboot是2024年求职市场上最常被问到的后端框架之一，拿它来做这个题，一方面能覆盖真实业务需求，另一方面也能把框架核心能力完整落地一遍。这套系统面向的是学生、校医、辅导员和管理员四类角色，从在线挂号、门诊开药、药品库存，到健康档案和体检数据追踪，全部用一套数据模型串联。如果你也正在准备类似的毕设或者练手项目，这篇文章我会把从需求分析、表结构设计、后端业务实现到部署排坑的完整思路都讲一遍，尤其会解释清楚那些教程里不细说的“为什么”。
1. 医务室业务场景拆解：这个系统到底要解决哪些问题
1.1 别急着写代码，先把“医务室的一天”走一遍
做毕设最容易犯的毛病，是拿到题目就开写，结果做完一看，功能是齐全的，但根本不像一个真正能被医务室使用的系统。为了避免这个问题，我在动工前先花了一整天蹲在学校医务室观察流程，把一个典型工作日浓缩成了几条主线：
- 早上8点，学生因为感冒来挂号，校医询问症状后诊断，开出药方，学生去药房窗口取药。
- 上午10点，班级体检批次到访，校医需要把每个学生的身高、体重、视力、血压逐项录入。
- 中午休息时段，校医在Excel里统计前一周的就诊人数、病症分类，准备给后勤处写报告。
- 下午，药房发现常用感冒药库存不够，手工下采购申请。
- 有学生因运动扭伤来复诊，需要调出之前的诊疗记录做对比。
这个流程看起来简单，但仔细分析就会发现，它跨越了挂号、门诊、药房、档案、数据统计五块业务，而且这几块之间是有强关联的。挂号单要和当日排班绑定，诊断记录要关联到具体学生的基础档案，药方开出去之后要即时扣减库存，体检数据要能追溯到某个学期某次批次。如果只是像普通管理系统那样做一堆CRUD页面，数据之间是割裂的，医务室老师用起来反而更麻烦。
1.2 用户角色和功能权限怎么切分
系统里最核心的交互角色其实是三类：学生、校医、系统管理员，在这个基础上还可以扩展出辅导员查看本班学生健康状况的功能。角色不同，看到的数据范围完全不同，这一点在需求阶段最容易被忽视。
- 学生端：能查看自己的健康档案、体检记录，在线完成挂号/取消挂号，浏览医务室公告和健康科普。
- 校医端：处理候诊队列，录入病历和处方，管理药品基础信息和库存，维护学生体检数据，查看数据统计。
- 管理员端：负责账号分配、角色配置、院系班级维护、基础代码表管理（比如疾病分类、药品分类）。
- 辅导员端（可选）：只能查看本班学生的整体健康统计，不能查看病历明细——学生隐私是设计红线。
我当时在数据库设计里把用户表拆成了sys_user和member_info两张表。sys_user只存账号、密码、角色等登录凭据，member_info存学生或教职工的业务信息。这样做最大的好处是：系统以后如果要扩展教师体检、访客预约，不需要改动登录模块，只要往member_info里加类型字段即可。
1.3 边界控制同样是需求的一部分
做医疗类系统，边界一定比功能重要。比如学生端是否允许修改自己的健康档案？显然不允许，只能提交修改申请，由校医审核后覆盖；在校医端是否允许删除已经归档的诊断记录？我们做的是逻辑删除，保留修改日志；体检数据是否允许学生直接查看？允许，但涉及过敏史和传染性疾病的部分做了单独权限。这些边界条件在写代码之前就要明确写进需求文档，因为直接决定了后端的接口设计和数据库的字段约束。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 技术选型与基础框架搭建：让毕设既有深度又不容易翻车
2.1 技术栈选择的实际考量
标题里直接带上了springboot，可见后端框架没有太多悬念。但配套技术栈的决定，我斟酌了很久。最终采用的是：Spring Boot 2.7.18 + MyBatis-Plus 3.5.x + MySQL 8.0 + Redis + Vue 3 + Element Plus。为什么是这套组合，而不是其他高大上的方案？
- Spring Boot 版本不要追新。很多同学一上来就装3.x，结果发现大量老教程里的配置写法失效，网上搜到的解决方案又都是针对2.x的，越调越乱。我自己在项目里经历过Spring Boot 版本太高导致的依赖冲突——swa