基于SpringBoot的在线诊疗管理系统设计与实现全流程指南

做毕业设计选到“在线诊疗管理系统”的同学，第一反应大概都是“这题目是不是有点大”——SpringBoot、在线诊疗、远程就医这些词堆在一起，听起来像要做一个完整产品。但实际动手拆开看，这个方向反而是近几年Java类毕设里性价比很高的一类：业务场景贴近现实、技术栈主流、扩展点多、答辩好讲，就算以后拿去包装成求职项目也拿得出手。我前后帮某位开发者的毕设项目做过整套技术方案梳理，也帮他排过联调期的坑，今天把这一条完整路径拆开来说。

这篇东西围绕“基于SpringBoot的在线诊疗管理系统”展开，从需求边界、技术选型、数据库设计、核心模块实现，到前后端联调阶段的高频问题和排查思路，全流程都会覆盖。适合两类人看：一类是正在选型、正在写代码的Java方向毕业生，另一类是准备用SpringBoot快速搭一套业务系统的初学者，哪怕你没接触过医疗行业，看完也能知道这类管理/服务类系统的通用打法。

1. 项目整体设计与技术选型

1.1 需求边界怎么划才不会被拖死

毕设项目最容易翻车的点不是写不出来，而是把需求想得太大。“在线诊疗”落到一个学生的毕业设计里，如果照着真实互联网医疗平台的样子去做——智能分诊、电子病历共享、医保对接、药品物流跟踪——那半年都做不完。正确做法是先把核心链路定住，其他全是可选项。

我给某开发者梳理需求时，第一件事就是把功能切成三层：

• 核心链路：用户注册登录 → 选择科室/医生 → 在线问诊 → 医生写诊断/开处方 → 用户查看处方并模拟支付 → 问诊记录归档。
• 支撑管理：后台的医生信息维护、科室维护、排班管理、问诊订单管理、用户管理。
• 加分项（有余力再做）：健康档案、用药提醒、问诊评价、数据统计看板。

把核心链路走通，项目就已经能演示、能答辩了。支撑管理是管理员端的基础操作，工作量其实不大，但能体现完整性和工程意识。加分项里挑两个做就行，比如评价功能和最简单的统计图，用ECharts套个接口就能搞定，性价比极高。

这个思路的底层逻辑是：毕设评分的核心依据是“系统是否完整可用”和“工作量是否达标”，而不是“功能是否像大厂产品”。你把一个闭环做好，比十个半成品拼接强太多。

1.2 技术栈选型的实际考虑

SpringBoot做主框架基本没有争议，但具体选型有几个地方容易被忽视。

• 持久层框架：MyBatis-Plus 比原生 MyBatis 更适合毕设。原因很现实：单表 CRUD 的代码量会砍掉 70%，分页插件、逻辑删除、自动填充这些功能都是内置的，能帮你把时间留给核心业务逻辑。
• 数据库：MySQL 8.0。这个版本对 JSON 类型和窗口函数支持不错，后面如果做统计功能会方便。字符集记得用 utf8mb4，不要只写 utf8，否则用户填个生僻字或者表情符号就乱码。
• 缓存：Redis 一定用上，哪怕只用两个场景也行：短信验证码存储、Token 管理。面试和答辩问起为什么用 Redis，这两个场景就足够讲清楚。
• 权限方案：Spring Security + JWT。有人觉得 Spring Security 配置复杂，想用拦截器硬写，我劝你别省这个功夫。Spring Security 的过滤器链虽然上手要花点时间，但它对密码加密、Session 管理、URL 级权限都有成熟方案，代码规范性和安全性比手写拦截器强得多。技术上用 BCrypt 加密密码，这是不可逆哈希，不是可逆的，千万别自己搞 Base64 或 MD5“加密”，答辩老师一眼就能看出问题。
• 前端：Vue2 或 Vue3 + Element UI。毕设阶段用 Vue2 + Element UI 的资料最全，遇到问题随便一搜都是答案。Vue3 也行，但别把时间耗在组合式 API 的学习上，业务代码其实用不到多少复杂特性。
• 接口文档：SpringDoc 或 Knife4j 二选一。把 Swagger 集成进去，光这个能让你在答辩演示时省很多事，不用把几十个接口一个个手动输到 Postman 里。

这套组合的现实优点很直接：主流、资料多、社区踩坑记录丰富。还有一个隐藏优势，就是你可以理直气壮地回答“为什么用 XXX”——因为这套技术在行业内本来就是这个场景下的常见选择，不是随便选了个冷门框架。

2. 数据库设计与核心表结构

2.1 核心表怎么梳理

数据库设计是很多人的噩梦，尤其是第一次做这种带状态流转的系统。其实不需要一上来就画十几张表，先把核心实体圈出来：用户、医生、科室、问诊订单、问诊消息、处方、药品、排班。

围绕这套业务，我给某开发者定了一个 10 张表的方案，这里列主要几张：

用户表（sys_user）和医生表（doctor_info）拆开，这是很多人容易犯迷糊的地方。用户和医生虽然在业务上都是“人”，但字段差异很大：用户侧重手机号、身份证、健康信息；医生侧重执业编号、职称、科室编号、擅长领域。如果强行合并成一张表，会产生大量空字段，后患无穷。

科室表（department）要预留排序字段和描述字段，别只写个名字。管理员后台展示科室列表时，如果没排序字段，显示顺序就是插入顺序，改起来麻烦。

问诊订单表（consult_order）是整张表结构里的核心，它不只记录订单状态，还把支付金额、支付方式、支付时间、医生回复时间、患者确认时间全部集中记录，方便统计和复盘。

处方表（prescription）和药品表（drug）之间是中间表关系，不要直接在处方表里存一串药品 ID 用逗号分隔，那是给以后埋坑的典型做法，至少要建一张处方明细表（prescription_item），每条记录存处方 ID、药品 ID、数量、用法。

排班表（schedule）是医生的出诊安排，字段包含所属医生、日期、上午/下午、剩余号源、总号源。问诊下单时先锁剩余号源，这就是“并发控制”的体现，答辩时能讲的东西一下就多起来了。

问诊消息表（consult_message）是用来存医患对话记录的，每条消息记录发送者类型，是用户还是医生，这样能支持异步查看历史对话。

2.2 建表时的关键坑位

第一，尽量给所有表都加create_time、update_time两个时间字段。MyBatis-Plus 的字段自动填充功能可以帮你写入，成本几乎为零，但做列表排序、做统计报表时它就是命根子。

第二，金额字段用DECIMAL(10,2)，float和double都不要用。Java 里对应BigDecimal。虽然这是老生常谈，但每次都有人的订单金额对不上，最后发现就是类型选错。

第三，状态字段用tinyint而不是varchar。比如问诊订单做四种状态：待支付（0）、待回复（1）、已完成（2）、已取消（3）。用数字的好处是状态流转判断写起来简单，而且可以加注释说明含义，不会看代码看得一头雾水。

第四，索引别乱加。核心索引放在这些位置：用户表的手机号、订单表的用户 ID、订单表的医生 ID、排班表的医生 ID + 日期。其他字段不要为了“看上去专业”就疯狂加索引，反而拖慢写入速度。

3. 核心模块实现过程

3.1 认证与权限控制的完整落地

这是整个系统的地基，也是第一个容易劝退人的模块。我用“Spring Security + JWT”的模式拆解一下实现思路。

流程是：用户提交手机号和密码，后端校验通过后生成一个 JWT，把用户 ID 和角色（USER、DOCTOR、ADMIN）塞进 Token 里，前端把 Token 存在 localStorage，每次请求在请求头里带上Authorization: Bearer <token>，后端过滤器从 Token 解出身份，放到 SecurityContext 里。

代码结构大概是：

// 登录接口核心逻辑 public LoginResponse login(LoginRequest request) { User user = userService.getOne( new LambdaQueryWrapper<User>() .eq(User::getPhone, request.getPhone()) ); if (user == null || !BCrypt.checkpw(request.getPassword(), user.getPassword())) { throw new BusinessException("手机号或密码错误"); } String token = jwtUtil.generateToken(user.getId(), user.getRole()); return new LoginResponse(token, user.getRole()); } // JWT 生成 public String generateToken(Long userId, String role) { return Jwts.builder() .setSubject(String.valueOf(userId)) .claim("role", role) .setIssuedAt(new Date()) .setExpiration(new Date(System.currentTimeMillis() + 1000 * 60 * 60 * 24)) .signWith(SignatureAlgorithm.HS256, SECRET_KEY) .compact(); }

JWT 密钥不要硬编码在代码里，放到application.yml的配置项中，答辩时还会被问“万一密钥泄露怎么办”，你至少能说“生产环境会放到配置中心或环境变量”，这句话就能堵住追问。

Spring Security 配置里需要定义一个过滤器，继承OncePerRequestFilter，从请求头拿 Token，如果合法就向 SecurityContext 写入一个UsernamePasswordAuthenticationToken。禁用 Session 创建，改用无状态模式。

这块最容易出的问题是非前端同学不理解“无状态”到底是什么意思。简单类比：以前 HTTP 每次请求都不认识你是谁，所以要靠 Session 存“登录标记”；现在我把“你是谁”这个信息直接放进一个签过名的 JWT 里，服务器不用存任何东西，验签就行。有点像演唱会门票，盖章在手上是 Session，带一张防伪二维码是 JWT。

3.2 在线问诊流程的实现细节

在线问诊是核心中的核心，但实现难度其实并不高，本质就是一个“状态机 + 消息记录”的流程。

问诊入口处，用户选择医生后先看排班。排班数据按“日期 + 医生”查询，前端用日历组件展示，后端接口只需返回该医生某段时间内的排班列表。用户选中某个时段，创建订单，订单状态为待支付。

支付这一步，毕设项目不建议真去对接支付网关，要做的是“模拟支付”：把支付按钮的文案改成“模拟支付”，点了之后直接置为已支付，并调用支付回调逻辑，把订单状态推进到待回复。这里如果你想体现一点工程深度，可以写一个PaymentService接口，提供mockPay()方法，内部调用消息队列或本地事件，把支付结果异步通知给订单模块。不需要真的引入 MQ，用 Spring 自带的事件机制就能实现，但写法和思路是对的，答辩能讲半小时。

医生侧的逻辑值得认真写一遍，因为这是体现“业务理解”的地方。医生登录后，在“我的问诊”列表里看到所有待回复订单，点击进入问诊室。房间不能直接静态做，而要动态生成对话记录。消息表的插入操作要同时更新订单的最后消息时间，方便列表排序。

处方是问诊流程的终点。医生点击“开处方”，选择药品、填写剂量和用法，后台会校验该订单是否已结束，如果已结束则拒绝操作。处方保存之后，订单状态自动改成已完成，用户侧才能看到“医生已开处方，请前往查看”。

实际操作里，这里的接口设计有一个值得抄作业的点：所有状态变更都走一个OrderStatusService，统一管理状态流转合法性和日志记录。比如状态从待支付直接跳到已完成，这个动作要被拦截，因为中间缺了支付和答复两个步骤。否则以后改点逻辑，状态判断散落在各处，排查起来非常痛苦。

3.3 处方与订单的闭环设计

处方模块容易做得“想当然”，也就是只把结果写成一张表，然后前端静态展示。但一个完整的处方要有几个动作：创建草稿、提交、医生签名（数字签名，不搞手写板）、作废、用户确认。毕设至少保留提交和作废两个动作即可，但状态要写入处方表。

另一个容易忽略的是“用户看了处方，怎么确认收到”。我的做法是：用户端提供“确认收方”按钮，这对应真实场景里的处方审核/签收环节。用户点确认后，订单才最终完结。这一步能体现系统完整性和对医疗业务流程的理解。

药品表要做基础的库存校验：

public synchronized void reserveStock(Long drugId, Integer count) { Drug drug = drugMapper.selectById(drugId); if (drug.getStock() < count) { throw new BusinessException("药品库存不足"); } int updated = drugMapper.deductStock(drugId, count); if (updated == 0) { throw new BusinessException("药品库存不足，请刷新后重试"); } }

deductStock的 SQL 使用原子更新UPDATE drug SET stock = stock - #{count} WHERE id = #{id} AND stock >= #{count}，这样就能避免高并发下库存被扣成负数问题。

3.4 管理员后台的功能怎么搭得更聪明

后台管理系统很多人喜欢全部手写，结果接口数量翻一倍，联调时间指数级增长。更聪明的做法是把通用增删改查做成基类，核心思路是泛型抽取。

例如，BaseController<T>里统一处理分页查询、根据 ID 查询、新增、修改、删除，子类只需要声明实体类型和模型类型。

public class BaseController<T> { @Autowired protected IService<T> service; @GetMapping("/page") public Result page(PageQuery query) { Page<T> page = service.page(new Page<>(query.getPageNum(), query.getPageSize())); return Result.success(page); } @PostMapping public Result save(@RequestBody T entity) { service.saveOrUpdate(entity); return Result.success(); } }

管理员端的科室、药品、排班这些模块，80% 的接口可以直接走这套基类，你不用为每一个模块都写一个独立的五连接口。但要注意，涉及业务校验的接口（比如删除有排班记录的科室）必须重写做好拦截，这点不能省。

4. 前后端联调中的高频问题与实战排查

4.1 跨域问题——报错第一杀手

只要前端页面不是和后端跑在同一个端口，就一定会有跨域问题。Spring Boot 里最简单的解决方法是写一个配置类实现WebMvcConfigurer，配置允许的跨域来源。但要注意，如果用了 Spring Security，跨域配置不仅要放在 MVC 层，Security 的过滤器链也要允许 OPTIONS 请求，否则前端预检请求就被拦截了。

前端踩过坑的一个典型表现是：登录接口直接调不通，控制台报错 CORS，但后端日志里一切正常。排查顺序是：先用浏览器直接访问后端接口看通不通 → 通的话再测带预检的跨域请求 → 不通就查过滤链。

4.2 前端拿到 401 后跳转逻辑混乱

JWT 过期后，前端拿到的响应码是 401，但很多同学只在登录拦截器里处理了 403，没处理 401，导致 Token 过期后页面一直停留在“数据加载失败”的空白状态。

正确做法是在前端 axios 响应拦截器里统一处理：

service.interceptors.response.use( response => response, error => { if (error.response.status === 401) { localStorage.removeItem('token'); window.location.href = '/login'; } return Promise.reject(error); } );

4.3 时间字段前后端相差 8 小时

用户看到的问诊时间永远比实际时间早 8 小时，这是没配置 Jackson 时区导致的。解决方法是在application.yml中统一配置：

spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT+8

如果是 LocalDateTime 字段，还建议在实体上使用@JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss")标注，双保险。

4.4 常见问题速查表

4.5 联调阶段的独家避坑建议

写接口之前，先把前后端字段名定死。不要把用户对象传到前端时带上密码字段，MySQL 查询也不要select *。建议统一用 Result 包装类，结构固定为{ code, message, data }，这样前端拦截器只需要处理三种情况：code=200、code=401、其他业务异常，逻辑简单很多。

后端接口的出参里，尽量用 DTO 而不是直接返回实体类，尤其是列表接口。直接返实体类习惯一旦养成了，以后每次加字段都可能把不该暴露的东西暴露给前端。最让人后怕的情况是用户表把密文字段加密了，结果前端拿到了加密后的密文，又被二次明文落库，最后密码校验永远不过。这类连环问题查起来会非常折磨。

日志要打好，这是排查问题的基本功。统一用抽象好的业务日志框架，在关键状态变更处加 info 日志，比如“订单 123 已从待支付变更到待回复，操作人：医生ID 45”。很多同学觉得日志是给生产环境写的，自己开发时用不上，真出事就靠 debug 一步步点，效率极低，尤其是状态流转类的问题，根本没法靠断点去追溯之前的路径。

5. 关于性能和安全的几点思考

毕设评审还喜欢问“系统安全怎么做的”和“并发量大的时候会不会挂”。前者主要靠 Spring Security、BCrypt 密码加密、JWT Token 校验、参数校验注解这些体现。后者可以拿 Redis 缓存热点数据来说：科室列表、医生列表、排班信息都可以缓存，减少数据库压力。

线程池单独说一下。我在项目中给某开发者留了一个ThreadPoolConfig，专门给消息通知这类非核心操作用——比如问诊结束后推送提醒、短信发送。把这种非关键操作丢进线程池异步执行，能让接口响应速度有明显改善，而且代码结构也更清晰。但一定要讲清楚线程池的“坑”：没有指定拒绝策略时，默认策略是 AbortPolicy，线程池满了直接抛异常。毕设开发阶段规模小，问题暴露不出来，但如果架构不提前规划，后面扩展时会被坑得很惨。

在线诊疗还有一个特殊敏感点：用户健康数据的隐私保护。这是不管你如何取舍都必须保留的模块，哪怕实现得简单一点。毕设能讲出“患者数据加密存储、会话内容不落日志、权限隔离”这一套，整个项目答辩的档次就高了。我建议至少把用户表手机号这类敏感字段做脱敏展示，问诊消息记录不允许非本人账号访问。哪怕只是用几个注解和权限校验实现，也比完全不设防强。

6. 从毕设到完整项目的扩展空间

如果你做完之后感觉意犹未尽，或者打算把这个项目包装成自己的代表性项目，有几个方向性价比很高：

• 引入消息队列：把模拟支付改成真实异步通知，用 RocketMQ 或 RabbitMQ 把支付、短信通知、订单状态更新串成生产者-消费者模式。
• 引入分库分表概念：虽然单机用不上，但可以把订单表按月份做分区，结合 ShardingSphere 讲思路。
• 增加 WebSocket 实时聊天：在线问诊的对话模块改成实时双工通讯，体验上立刻接近真实产品。
• 增加文件服务：把检查报告上传、下载的功能补上，用本地存储或阿里云 OSS 模拟文件服务器，这是一个非常好的扩展点。
• 增加数据看板：管理员端用 ECharts 做每日问诊量、科室分布、医生工作量排行，能直接补足统计类功能的缺失。

每一条都值得在答辩时展开，因为它们不是开发框架功能，而是“业务如何借助技术落地”的思路，这比单纯背 JWT 和 Redis 概念要加分得多。

我个人在实际操作中的体会是，毕设项目里真正让人成长的并不是框架用得多花哨，而是那个“从需求到设计再到代码落地和问题排查”的完整过程。尤其是这种带状态流转、带权限体系的系统，做一遍之后，你再看其他业务系统的代码结构，眼睛会尖很多。最后再分享一个小技巧：毕业设计的项目管理一定要早一天把“重建环境”的步骤写出来。数据库 SQL 脚本、Redis 配置、后端启动参数、前端 node 版本，全部写进 README。不要等到答辩前一晚，换一台电脑、连不上数据库、项目起不来，那时候会发现这件事才是最重要的。