Spring Boot校园智慧医疗小程序：在线问诊至电子病历全解析

毕业设计选型那阵子，我翻遍了各种系统，什么“基于Spring Boot的医院挂号系统”“校园二手交易平台”“在线题库管理系统”，看来看去都大同小异。直到看到“基于Spring Boot的校园智慧医疗助手小程序”这个方向，我眼前一亮：它既有Spring Boot后端、又有小程序前端，还带移动应用场景，技术栈完整，业务逻辑也比普通的CRUD有意思得多。后来我把它拆成“大学生就医服务移动应用”来做，前前后后从选题、搭框架、写接口、调联调，到最后答辩，踩了不少坑，也总结出一套可以复用的经验。这篇就把完整的过程和核心设计思路整理出来，给正在纠结毕设选题或者准备做同类项目的同学一个参考。

这个项目本质上不是一个单纯的信息管理系统，它模拟的是一个真实的就医服务闭环：学生在线问诊、校医院医生接诊、开处方、出电子病历、药品提醒，管理员在后台做统计和审核。你要面对的不仅是“增删改查”，还要想清楚角色权限怎么划分、状态机怎么流转、消息怎么推送、并发和异常情况怎么处理。这些思考过程恰恰是答辩时最能加分的部分。适合谁看？如果你正在做Spring Boot相关的毕设，想选一个有深度但又能在几个月内做完的方向，或者已经选了类似题目但不知道从哪里下手，这篇文章应该能帮你把整体框架、核心功能和技术细节一次性理清楚。

1. 毕业设计选题背后：为什么是“就医服务”而非“挂号系统”

很多人看到这个题目会下意识觉得，“校园智慧医疗助手”就是做预约挂号。做下去才发现，如果只做挂号，这个项目的技术展示面太窄。真正的看病流程是“问诊—开方—取药—随访”，挂号只是入口。把整个就医闭环搬进一个小程序，至少能拆出十多个有实际业务含义的模块，每一个模块都有独立的技术难点，这才是这个题目的核心价值。

1.1 校园场景里真实存在的痛点

我在设计这个项目时，先花了几天时间观察校医院的实际情况。校医院的特点是：科室少、医生少、但学生数量大，就诊时间又集中在课间和饭点。学生去看病往往要排队半小时，真正面诊只有几分钟；开完药之后医生叮嘱的内容很容易忘记；复诊时还要重新说一遍自己的症状和病史。这些问题靠一个传统的“挂号系统”根本解决不了。

所以产品定位应该是“连接学生和校医院医生的轻量级服务平台”，而不是一个“线上排队叫号机”。我把它拆成三个核心诉求：

• 减少非必要的到院咨询——能在线问清楚的小问题，就不必专门跑一趟；
• 让问诊信息留痕——学生自述症状、医生诊断、用药建议都在线上可查；
• 让简单流程自助化——预约、挂号、查看报告、历史病历，学生自己就能搞定。

这三点直接决定了功能列表的优先级。比如“健康资讯”这种锦上添花的内容，可以放在后期开发；而“电子病历”和“处方单”则是整个项目的数据核心，必须优先设计。

1.2 角色权限设计：先划分再设计模块

做这类项目最容易犯的一个错误是角色不分清，代码写到最后全是if else。我建议第一时间把系统角色收敛为三种：学生端、医生端、管理员端。

注意，这里的“医生端”不需要单独做一个App，在小程序里通过角色切换就能实现。一个账号在后台绑定角色，登录后根据角色路由到不同首页。这样页面可以共用一个代码工程，大大减小前端工作量。

模块划分清楚了，再去做接口设计就顺很多。学生端和管理端的字段要求是天然不同的，比如同一个“用户表”，学生有学号、学院、班级，医生有职称、科室、排班时间。如果一开始就用一个大用户表塞所有字段，后面扩展会很痛苦。我后来是拆成了user主表加student_profile、doctor_profile两张子表的方式，各模块只关心自己需要的字段，逻辑清晰。

2. 技术栈选型：Spring Boot + 小程序为什么是毕设最优解

这个部分聊聊我当初是怎么选型的。不是说某个技术“流行”就选它，而是要看它能不能在有限的时间内稳定支撑整个业务闭环，并且让答辩老师看到你的工程能力。

2.1 后端框架：为什么直接锁定Spring Boot

如果你问十个做过毕设的人，九个会推荐Spring Boot，剩下一个推荐你换题目。Spring Boot的优势不算什么秘密：内嵌Tomcat、自动化配置、starter机制，能让你把精力集中在业务代码而非繁琐的XML配置上。

但我想多说一点。毕设项目最重要的是“可演示、可维护、可扩展”。Spring Boot天然支持前后端分离，你可以把后端纯粹做成RESTful API，小程序端和Android端共用同一套接口。我当时是先写后端接口文档，再用Postman调试，最后才写前端页面，整个过程非常顺畅，基本没有因为接口定义不清来回返工。

对比一下：如果选传统的SSM框架，配置Spring和MyBatis就要花不少时间，而且时代感太强；如果用Node.js或者Python Flask，虽然写起来更轻快，但和“计算机科学与技术”专业的课程主线不完全贴合，答辩时容易被追问为什么不用Java。Spring Boot是风险最低、性价比最高的方案。

2.2 数据访问层：MyBatis-Plus的取舍逻辑

数据访问层我有过很长时间的纠结。JPA写起来优雅，自动建表也很方便，但复杂查询一旦踩到性能和SQL方言的坑，调试成本很高。原生MyBatis灵活，但每个表都要手写Mapper接口和XML，工作量不小。

最终选了MyBatis-Plus，原因是它站在两者的中间：分页插件、条件构造器、逻辑删除都是开箱即用的，同时保留了XML写复杂SQL的能力。核心代码里，简单的单表操作直接用Wrapper条件构造器，多表联查再单独写XML，开发效率提升了不止一倍。

不要小看这个选择。答辩时老师问“你的项目里分页查询怎么实现的”，你可以很清楚地说出用了MyBatis-Plus的Page对象配合拦截器，同时自己通过explain分析过慢查询，这在细节上是很加分的。

2.3 身份认证：用JWT还是Session

高校项目里登录认证一般两个流派：Session/Cookie派和JWT派。我推荐后者。原因是小程序端和Android端都没有传统意义上的Cookie机制，SessionId跨端保持很麻烦；而JWT是无状态的，客户端每次请求在Header里带上Authorization: Bearer <token>即可，服务端只管验签，不需要存储登录态。

具体实现上，我用jjwt库生成token，在拦截器里统一校验，token过期后返回401，前端再跳转到登录页。这里有一个容易踩的坑：小程序里保存token要用wx.setStorageSync，请求时通过自定义Header传入；Android端则要维护一个拦截器来统一附加token。两端的处理逻辑不一样，不能照搬一套。

2.4 小程序和Android端怎么共用一个后端

题目里既提到了“小程序”，又提到了“Android”，看上去像两个项目，其实不然。我的做法是：小程序作为主端，承担核心业务闭环；Android端复用后端接口，做一个精简版的门户客户端。Android端的核心功能可以只保留“首页问答展示、在线问诊、个人中心”，因为接口路径和数据结构完全一样，只是网络层换成OkHttp或者Retrofit即可。

这样既满足了题目名里的“SpringBoot+Android”，又不会把工作量翻倍。答辩表述上，我会强调“双端复用同一套API设计”，既体现了后端接口的规范性，也说明了前端跨平台能力。千万不要傻乎乎地分别写两套后端，那纯粹是浪费时间。

3. 核心场景落地：在线问诊模块的设计与实现

在线问诊是整个项目最核心的模块，没有之一。它的难点不在于“发消息”“存记录”这种单点操作，而在于整个业务状态是有流转的：学生发起问诊，医生接诊，双方对话，医生开方，学生确认。任何一个环节的接口设计失误，都会导致数据错乱。

3.1 问诊单的数据模型与状态机设计

首先，问诊不能直接做成“聊天室”。聊天是流动的，而医疗场景需要“病历留痕”——学生问的问题、医生的回复、开出的处方，必须结构化地挂在某一次问诊单下。所以核心表是consultation（问诊单主表），围绕它扩展消息和处方子表。

consultation表的几个关键字段：

• id、student_id、doctor_id
• status：0待接诊，1问诊中，2待开方，3已完成，4已取消
• symptom_desc：学生自述的症状描述
• created_time、finish_time

为什么设置“待开方”这个状态？因为医生和学生的对话可能结束了，但处方还需要时间填写。如果没有这个中间态，学生端会误以为问诊没结束，医生端又不知道下一步该干什么。状态机越明确，前后端逻辑越简单。

这里分享一个经验：所有状态变更的接口，必须校验当前状态是否等于预期的前置状态。比如“接诊”接口只允许0变成1，如果学生已经取消了问诊，这个操作必须返回一个错误码。用乐观锁或者版本号字段避免并发状态覆盖，这点在答辩里被问到概率很高。

3.2 问诊消息：轮询还是WebSocket

聊天消息的实现方式我也纠结了一阵。初期图省事用轮询，也就是前端每隔几秒调一次“查询新消息”接口。实测发现两个问题：一是延迟感明显，学生发完消息要等几秒才能看到医生回复；二是服务端压力大，一个问诊室的轮询请求密度非常高。

微信小程序里其实有原生WebSocket能力，于是我的方案调整为：建立问诊室时通过WebSocket建立长连接，服务端推送新消息；退出问诊室时主动断开。WebSocket的地址通过后端的/ws/consultation/{roomId}生成，握手时在URL里携带JWT，服务端用拦截器校验身份。

同时保留数据库消息表chat_message落库，这样即使消息推送失败，前端下次进房间也能通过HTTP接口拉取历史记录，保证数据不丢。WebSocket只负责“实时通知”，不负责“持久化存储”，职责分离，实现起来反而简单。

3.3 问诊创建与医生接诊的核心代码演示

学生端发起问诊时，前端提交症状描述和预约科室。后端创建问诊单，同时从科室维度找当前空闲的医生。简化后的核心逻辑如下：

@PostMapping("/consultation/create") public Result createConsultation(@RequestBody ConsultationDTO dto, @RequestHeader("Authorization") String token) { // 1. 解析token获取学生信息 Long studentId = JwtUtil.parseToken(token).getUserId(); // 2. 校验学生当前是否有未完成问诊单，防止重复创建 Integer activeCount = consultationMapper.countActiveByStudent(studentId); if (activeCount > 0) { return Result.error(400, "请先完成或取消当前问诊再发起新的问诊"); } // 3. 创建问诊单，状态为待接诊 Consultation consultation = new Consultation(); consultation.setStudentId(studentId); consultation.setDoctorId(null); consultation.setSymptomDesc(dto.getSymptomDesc()); consultation.setStatus(0); consultation.setCreatedTime(LocalDateTime.now()); consultationMapper.insert(consultation); // 4. 如果系统配置了自动分配医生，这里调用分配策略 Long doctorId = doctorDispatchService.dispatchBestDoctor(consultation.getId(), dto.getDeptId()); if (doctorId != null) { consultation.setDoctorId(doctorId); consultationMapper.updateById(consultation); } return Result.success(consultation); }

再看看医生端接诊的核心逻辑，这个接口的关键是防止两个医生抢同一张问诊单：

@PostMapping("/consultation/accept") public Result acceptConsultation(@RequestParam Long consultationId, @RequestHeader("Authorization") String token) { Long doctorId = JwtUtil.parseToken(token).getUserId(); // 乐观锁：必须status=0时才能更新为1 int updated = consultationMapper.acceptOrder(consultationId, doctorId, 0, 1); if (updated == 0) { return Result.error(409, "问诊单已被其他医生接诊或已取消"); } // 接诊成功后，可推送WebSocket消息给对应的学生 wsService.notifyStudent(consultationId, "医生已接诊，请开始描述你的病情"); return Result.success("接诊成功"); }

注意acceptOrder这条SQL的写法：

@Update("UPDATE consultation SET doctor_id = #{doctorId}, status = 1 " + "WHERE id = #{id} AND status = 0") int acceptOrder(@Param("id") Long id, @Param("doctorId") Long doctorId, @Param("oldStatus") int oldStatus, @Param("newStatus") int newStatus);

用一条带状态条件的UPDATE语句代替“先查再改”，在高并发下能天然防止重复操作。这个细节我强烈建议写进你的答辩亮点里。

3.4 处方与电子病历：如何避免数据矛盾

问诊完成后，医生要开处方。处方涉及到一个“幂等”问题：医生点击“提交”按钮时如果网络抖动，可能重复提交，导致一张问诊单下出现两条处方记录。解决方法是：写数据前先校验consultation.status必须是2（待开方），开方成功后再把状态改为3（已完成）。这个状态的流转是单向的，不可回退。

电子病历模块其实可以从问诊单数据衍生出来：学生基本信息、症状描述、医生诊断、处方明细、复查建议。不需要单独设计一套复杂的录入页面，医生在完成问诊卡片时把该填的字段填完，系统自动生成一份结构化的电子病历。这样既节省开发时间，也符合真实医疗场景“一次就诊一份病历”的直觉。

药品明细建议单独设计一个prescription_item表：一个处方对应多条药品记录，每个药品包括名称、规格、用法用量、天数、总剂量。不要图省事把多种药塞进一个逗号分隔的字符串字段，否则后期做“药品统计”或者“用药提醒”时会想哭。

3.5 小程序端的核心页面与交互细节

小程序端页面不需要太多，但每一页都要干净。重点页面最多五六个：

• 首页：科室列表、快捷入口（预约挂号、在线问诊、报告查询）；
• 问诊室：聊天窗口、症状描述卡片、状态提醒；
• 预约页：科室、医生、时间段的选择；
• 处方详情页：药品列表、用法用量、总计费用；
• 个人中心：历史问诊、病历夹、健康档案设置。

交互上有两个细节值得留意。一是问诊室顶部要实时显示当前状态，比如“等待医生接诊中”“本次问诊已结束”，避免学生一头雾水。二是药品用法用量要用大字号、分条目展示，不能挤在一起看得眼花。联系人页面往往只写功能，不写体验，但这些细节恰恰是演示时最能打动答辩老师的地方。

4. 开发中绕不开的坎：常见问题与调试心得

讲完模块设计，再说说真正动手之后会遇到的一堆麻烦事。这些坑我基本都踩过一遍，提前知道能少熬夜。

4.1 时间字段引发的连锁报错

第一个坑就是时间。后端用LocalDateTime，返回给前端的默认格式是2025-01-01T10:23:45，这种带T的格式在小程序里直接渲染会很难看。而MySQL数据库如果用的UTC时区，查出来的时间还会比北京时间早8个小时。

解决办法有两步。第一，实体类的LocalDateTime字段上增加@JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss", timezone = "GMT+8")注解，保证接口输出格式一致。第二，在数据库连接串上显式加上serverTimezone=Asia/Shanghai，避免依赖服务器默认时区。这两个配置都加好之后，时间问题基本能彻底解决。

4.2 小程序请求后端跨域和Session问题

小程序开发过程中，用“不校验合法域名”模式访问本地后端时，最容易碰到的就是跨域。Spring Boot后端需要配置CORS，在WebMvcConfigurer里重写addCorsMappings，允许所有来源、所有请求头。如果你用了JWT，还要注意：Access-Control-Allow-Headers必须包含Authorization，否则前端自定义请求头会被浏览器拦截。

还有一个隐秘的坑：Spring Security框架下，如果用默认配置，POST请求的CSRF校验会误伤小程序请求。如果没引入Spring Security，忽略这条；如果引入了，记得关闭csrf和cors配置并手动放行/api/**路径。

4.3 本地联调与真机预览的差异

本地调试好好的，用手机真机预览，发现图片加载不出来、请求超时。原因很简单：手机无法访问localhost，必须把接口地址改成电脑在局域网内的IP，比如http://192.168.1.101:8080。注意这个IP每次连网络都可能变，所以建议把基地址抽到一个公共配置里统一管理。

后端部署同理。如果你有云服务器，别用localhost，要绑服务器的公网IP，并在安全组放行8080端口。小程序上线还必须配置HTTPS合法域名，但毕设演示阶段用“开发模式-不校验合法域名”就好，这个不用紧张。

4.4 排查Bug的思路：先看日志再查接口

很多同学遇到Bug的第一反应是打开前端页面反复操作，这是效率最低的。我自己的经验是：先看后端控制台有没有打印异常堆栈，再通过Postman直接调用接口复现，最后才去精确定位具体是哪一层出了问题。90%的问题其实都能在Controller层和Mapper层的SQL日志里找到答案。

建议在application.yml里把mybatis-plus的日志级别调到debug，这样每次操作都能看到SQL执行情况和参数填充是否正常。SQL还能直接复制到Navicat里跑一下，看是不是数据本身有问题。这套方法论比单纯瞎猜靠谱得多。

5. 答辩演示与项目扩展：让分数上去的细节设计

代码写完不算完，毕业设计最后拼的是“表达”。很多同学代码写得不错，演示时却语无伦次，或者一被老师追问就慌了。以下是我根据自己的答辩经验总结的几个提升点。

5.1 演示脚本怎么设计最加分

演示别从登录页慢慢点，你要先讲清楚这个项目解决什么问题，然后直接进入最有技术含量的场景。我当时演示顺序是这样的：

• 一句话项目简介：面向校园场景的就医服务闭环；
• 演示在线问诊的完整流程：学生发起问诊，医生接诊，模拟双方聊天，医生开处方；
• 打开数据库展示数据表之间的关联，证明数据是真实落库的；
• 切换回学生端，展示处方详情和历史病历，说明同一个数据在不同端的呈现。

整个过程控制在8分钟以内，每个操作都提前排练过，不给老师太多打断的机会。注意，演示时不要把所有功能都点一遍，选择“问诊闭环”一条主线走通，比零散地把所有页面过一遍更有效。

5.2 容易被追问的技术问题清单

我把答辩老师大概率会问的问题提前准备好：

• 为什么用JWT而不用Session？（答：多端复用、无状态、支持跨域，与小程序场景匹配）
• 医生并发接诊你怎么处理？（答：数据库乐观锁保证状态原子性变更）
• 消息实时性怎么实现？（答：WebSocket负责实时推送，数据库落库兜底）
• 数据库表设计如何避免冗余？（答：用户主表拆子表、处方主表拆明细表，按角色维度建模）
• 项目还有哪些不足？（答：没有接入支付和语音视频问诊，后续可以扩展）

这些问题都不难，关键是你要真的有思考过，而不是背答案。把状态机画在纸上，把权限设计理清楚，答辩时底气足很多。

5.3 低成本高回报的功能扩展方向

如果时间和精力允许，还可以给项目加几个低成本亮点：

• 问诊结束后推送满意度评价，用一个小表存星级和文字反馈；
• 后台增加可视化统计，按科室、时段展示问诊量，用ECharts画柱状图和折线图；
• 药品库存提醒：当某药品余量低于阈值时，管理员后台弹出预警。

这些扩展不需要改动核心架构，但每一个都是能在答辩时拿得出手的“创新点”。对这种偏应用型的毕设来说，广度够了之后，做一两个点睛的深度功能，比堆功能数量更有性价比。

说到底，计算机毕业设计考验的不是你用了多牛的技术，而是你能否在有限时间内完成一个完整、自洽、可演示的项目。Spring Boot + 小程序的组合，胜在技术栈扎实、开发效率高、展示效果好。这个校园智慧医疗助手做完之后，我对“数据建模”和“状态管理”的理解明显比以前面试刷题时更深了一层。如果你也正在做类似的项目，别急着写代码，先把流程想透，把角色和状态定清楚，后面会顺利得多。真遇到问题，多半不是技术不会，而是前期设计欠了债，补齐这一块，整个项目就立住了。