Spring Boot+Vue智慧医疗系统拆解：预约挂号与排班设计

简介：一份基于SpringBoot+Vue的智慧医疗系统毕业设计论文文档，面向计算机、软件工程等专业学生及需要完成类似选题的开发者。内容以“康健智慧医疗平台”为实例，系统介绍医疗资源优化、患者线上就医、医患沟通等场景的实现思路，覆盖系统架构、B/S模式、前后端分离设计，以及用户管理、在线预约挂号、电子病历、健康数据分析、医生在线咨询等核心模块。文档还包含数据库选型、功能测试与总结展望，可作为毕业设计撰写和项目开发的直接参考。资源包为1个doc文件，大小2.59MB，方便直接阅读和修改。目前已有79人学习浏览，适合正在筹备医疗类毕设或想快速了解SpringBoot+Vue项目完整流程的读者参考。

1. 从“挂号难”到“排班可见”：一个二开友好的智慧医疗系统拆解

医疗信息化赛道里的毕业设计，常见毛病是“业务不少、落地稀碎”。预约挂号、电子病历、医生排班、在线咨询这些功能听上去都齐了，但真打开源码，要么是一张表打天下，要么是前端写死路由、后端全是重复的 CRUD。而这份“扁鹊智慧医疗系统”值得拆的点在于：它不是堆功能，而是把 Spring Boot + Vue 这套前后端分离骨架，按照“患者问诊 → 医生排班 → 处方闭环”的真实流程串了起来。和网上动辄几十张表的“全家桶”项目不同，它的表结构收敛到用户、科室、医生、排班、预约、病历、处方这几个核心实体，思路更像一线中小型 HIS 系统的精简版。对于正在做毕设、或者想拿一个干净项目做二开的开发者来说，它的参考价值不在某个炫技功能，而在“为什么这么设计”。

我的建议是，打开这套源码时别急着跑，先看src/main/resources里的数据库脚本和vue前端目录的router配置，把页面和接口的对应关系理清楚。这篇文章我会从架构选型、核心模块实现、预约防冲突、数据权限这几个角度，把它的实现逻辑掰开讲，并指出哪些地方值得照抄、哪些地方需要按生产标准改造。

2. 技术选型背后的工程权衡

2.1 Spring Boot 的自动配置对错：别把“方便”当“黑盒”

系统后端选择了 Spring Boot，这在 2024 年看似乎是理所当然的事，但毕设和课程设计里最常见的误区，恰恰是把 Spring Boot 的“自动配置”当成一个黑盒用：Application类一启动，数据库连接就神奇地有了，接口就能跑了。

细看这份实现里的几个关键依赖选型，能看出它对“能跑”和“能查”之间边界是有想法的。

首先是持久层。很多同类项目直接上 MyBatis-Plus，图的是 LambdaQueryWrapper 方便。这个项目用的是 Spring Data JPA 风格的仓库接口设计，实体类上的注解把表映射关系显式声明在代码里。对比来看：

对于医疗这种字段关联多、状态流转明确的业务，JPA 的实体关联能把“医生排班”和“预约挂号”的关系直接表达在代码里，比散落的 SQL 片段更容易保证完整性。

其次是接口风格。系统采用了前后端分离的 RESTful 接口设计，路径语义清楚：/api/appointment/**管预约，/api/doctor/**管医生信息，资源名用复数，HTTP 方法表达操作语义。但如果你把它部署到生产环境，会发现一个问题：跨域配置没有做细。默认的@CrossOrigin如果写在 Controller 上，等于对所有来源开放，这在医疗场景是不合规的。改造时应该抽取一个WebMvcConfigurer，用allowedOriginPatterns限定具体的前端域名，或者在后端网关统一处理。

2.2 Vue 组件化在前端页面里的落点

前端没有选择 Vue 3 + Vite，而是用了 Vue 2 生态的 Element UI，这个选择在今天看稍显保守，但就项目稳定性而言是合理的。组件化部分的重点不在于用了多少个.vue文件，而在于它对“复用”这件事的克制。

以“预约挂号”入口为例，前端拆了三个层级：

1. 顶层是appointment.vue，负责排班数据的拉取和日期选择；
2. 中间是doctor-card.vue，展示医生头像、职称、擅长领域；
3. 底层是time-slot.vue，渲染某位医生在某天的上午、下午时段和余号量。

time-slot.vue接收一个slot对象作为 prop，通过$emit('select', slot)把选中事件抛给父组件。这样做的好处是，同一套时间段组件后期可以复用到“我的预约”和“医生排班管理”页面。

但我注意到一个典型问题：组件的props没有做类型校验。团队协作时，如果后端返回的字段名从doctorName改成name，前端不会报错，只会在页面上显示空白，排查成本远比写一行type: String高得多。对一个想拿这份代码做二次开发的人来说，接手第一件事应该是去components目录下给每个组件的 props 补上validator函数。

2.3 运行环境与部署形态

系统要求 MySQL 5.7 版本，这在今天看来反而是个合理选择。MySQL 8.0 的认证插件是caching_sha2_password，如果后端连接的 JDBC 驱动版本过旧，会直接报Public Key Retrieval is not allowed。项目锁死 5.7，等于把数据库连接这块最大的变量排除掉了，自己在自己机器上跑的时候不用折腾驱动。

Tomcat 9 + JDK 8 的组合也是同样道理：Spring Boot 2.x 内置 Tomcat 9，JDK 8 是绝大多数高校机房和答辩机器的默认环境，不会出现“在我电脑上能跑”的尴尬。

3. 后端接口是如何围绕“医患关系”展开的

3.1 用户体系的三角色设计与数据隔离

这套系统的用户管理没有粗暴地把“患者”和“医生”塞进一张大表，而是拆了user、patient、doctor三张表。user表存账号密码和角色标识（1 管理员 / 2 医生 / 3 患者），patient和doctor表通过user_id关联用户账号，各自存业务属性。

这个设计的好处很直接：登录验证统一走user表，而业务操作按照角色去各自的业务表补充信息。UserController里的登录方法，校验通过后返回一个包含用户 ID、角色、用户名的 JSON，前端拿到后存到localStorage，之后每次请求在请求头带token参数。

预防越权访问，方法是在拦截器里校验角色码：

@Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String requestUri = request.getRequestURI(); if (requestUri.startsWith("/api/admin/")) { Integer role = (Integer) request.getSession().getAttribute("role"); if (role == null || role != 1) { response.setStatus(403); return false; } } return true; }

提示：这套系统的权限拦截是基于方法前缀匹配的粗糙做法，/api/admin/**归管理员，/api/doctor/**归医生，/api/patient/**归患者。它的优点是看得懂，缺点是@RequestMapping一旦写成模糊路径就可能绕过，例如请求/api/doctorInfo就不匹配/api/doctor/的前缀规则。生产环境建议换成注解权限或 Spring Security 的@PreAuthorize。

3.2 预约挂号的防重复与防冲突

预约挂号是这套系统里最容易出并发问题的地方。如果不做控制，两个患者同时点击同一个剩余号源的“预约”按钮，数据库扣减剩余号数就超卖了。

项目里的处理方式是在appointment表中增加唯一约束(schedule_id, patient_id)，用数据库层保证同一患者对同一排班只能有一条预约记录。同时在schedule表里维护一个remaining字段，预约成功时执行带条件的更新语句：

UPDATE schedule SET remaining = remaining - 1 WHERE id = ? AND remaining > 0

这行 SQL 是关键。先判断剩余号数大于 0，再执行减法，这一步没有加锁却避免了超卖，原理是数据库的单条 UPDATE 语句自带原子性。如果更新后受影响行数为 0，说明号已被抢完，Service 层抛出业务异常提示“号源已满”。

需要注意的点是：这种方式在高并发下仍然可能出现“余号显示为 1，但实际已约满”的短暂不一致。如果想进一步优化，可以在schedule表上使用乐观锁版本号字段，在 UPDATE 时加上AND version = ?作为条件，更新成功后 version 加一，冲突时让用户重试。

3.3 电子病历管理：状态机与前端表单

病历这块功能比普通 CRUD 复杂的地方在于它有状态流转：草稿 → 已提交 → 已诊断。设计的核心是诊断结果与预约记录挂钩，不再是对某个患者凭空录入一条记录。后端创建病历的流程是：

1. 医生点击“待就诊”列表里的某条预约记录；
2. 携带appointmentId调新开病历接口；
3. 后端通过appointmentId查出患者 ID、主诉信息，将患者关联到病历表；
4. 医生补充诊断内容和医嘱，状态置为“已诊断”。

这样设计让病历有了来源追踪，也是审计时最重要的凭证链路。业务实现时推荐的做法是在前端保存时把“诊断结果”和“处方”打包成一个 JSON 提交，后端用 DTO 接收，内部再拆两个表去持久化。

3.4 核心业务执行链路补全

后端这一套最值得“抄”的不是某个具体接口，而是事务边界的切分。下面把预约挂号到医生接诊再到开具诊断记录的完整链路补全：

@Transactional public AppointmentVO createAppointment(AppointmentRequest request) { Schedule schedule = scheduleRepository.selectForUpdate(request.getScheduleId()); if (schedule.getRemaining() <= 0) { throw new BusinessException("当前排班号源已约满"); } Patient patient = patientRepository.findByUserId(getCurrentUserId()); // 校验同一患者在同一时间段不存在冲突预约 boolean conflict = appointmentRepository.existsByPatientIdAndTimePeriod(patient.getId(), schedule.getStartTime(), schedule.getEndTime()); if (conflict) { throw new BusinessException("您在该时间段已有预约，请勿重复预订"); } scheduleRepository.deductRemaining(request.getScheduleId()); Appointment appointment = new Appointment(); appointment.setPatientId(patient.getId()); appointment.setScheduleId(schedule.getId()); appointment.setStatus("BOOKED"); appointment = appointmentRepository.save(appointment); return appointmentConverter.toVO(appointment); }

事务方法要加@Transactional并确保类被 Spring 管理，避免出现“自调用失效”。上面的selectForUpdate是悲观锁兜底，如果数据库隔离级别是默认的可重复读，它能保证同一排班记录在事务提交前不被并发修改。

4. 数据库设计：一张好的医生排班表是如何撑起整个系统的

4.1 排班模块的数据组织方案

医生排班是整个系统数据设计里最花费心思的地方。排班信息不能直接写在doctor表上，因为一个医生一周有两个以上时段出门诊，这对应着多条排班记录。

schedule表的最小属性集包含：id（主键）、doctor_id（外键关联医生表）、work_date（出诊日期）、start_time和end_time（时段分隔）、max_count（总号量）、remaining（剩余号量）。设计表结构时有一处容易忽略：work_date和start_time如果分开存，查询“某医生某天有哪些号源”时简洁，但比较某个时间段是否冲突时就费劲，需要用函数拼接再比较。

实际推荐的设计是在表中冗余一个period_startdatetime 字段，把日期和时间合并到一起。在doctorService.listAvailableSlots(doctorId, date)查询里这样写：

SELECT id, start_time, end_time, max_count, remaining FROM schedule WHERE doctor_id = #{doctorId} AND work_date = #{date} AND remaining > 0 AND work_date >= CURDATE() ORDER BY start_time ASC

时间段的建模比日期更需要留意。上午还是下午，如果只用一个time_slot字符串（如“上午”）来标识，后续排班规则扩展（如“仅工作日”）需要改表。作者把开始结束时间拆成两个datetime字段，这使系统具备支持分时段门诊的扩展能力——把上午拆成 8:00-8:30、8:30-9:00 等小段时，同一张表不需要改结构，只需插入不同记录。

4.2 患者健康数据表的智能分析支撑

健康数据分析模块背后依赖的不是一套算法，而是一张设计得当的health_record表。每次患者录入一条体检数据，包含patient_id、record_date、blood_pressure_high、blood_pressure_low、heart_rate、blood_sugar等指标字段。

生成简易健康报告时，查询最近 30 天的均值标准差：

public HealthReport generateReport(Long patientId) { LocalDate end = LocalDate.now(); LocalDate start = end.minusDays(30); List<HealthRecord> records = healthRecordRepository .findByPatientIdAndRecordDateBetween(patientId, start, end); double avgBpHigh = records.stream() .mapToInt(HealthRecord::getBloodPressureHigh) .average().orElse(0); double avgBpLow = records.stream() .mapToInt(HealthRecord::getBloodPressureLow) .average().orElse(0); // 血压超过 140/90 时给出预警提示 String suggestion = (avgBpHigh >= 140 || avgBpLow >= 90) ? "高压偏高，建议减少钠摄入并保持规律作息" : "血压处于正常范围，维持现有生活方式即可"; return new HealthReport(avgBpHigh, avgBpLow, suggestion); }

一份真正的电子病历系统，健康数据不是孤立存在的，它应该与病历表通过patient_id关联。这里的实现已经预留了关联查询的能力，前端在“健康档案”页面下可以说一句“基于近 30 天血压记录，您的均值处于正常偏高区间”，这比单纯展示曲线图更具实用性。

5. 测试边界、优化手法与生产化改造

5.1 一场常见的并发穿透测试

在测试预约接口的高并发写入时，给一张只有 5 个剩余号数的排班记录连续发 20 个请求。最终数据库里成功了 5 条，预约成功的消息返回了 8 次。问题就出在第一步的扣减和第二步的插入不在同一事务边界内，两个请求可能同时读到remaining = 1。

修复方案是给排班扣减加上SELECT ... FOR UPDATE：

@Query(value = "SELECT * FROM schedule WHERE id = :id FOR UPDATE", nativeQuery = true) Schedule findByIdForUpdate(@Param("id") Long id);

FOR UPDATE会让第二个请求的相同查询操作进入锁等待状态，直到第一个事务提交或回滚后，第二个请求才读到最新数据。紧接着用你先前准备的唯一约束兜底，重复提交的请求被数据库拒绝。做高并发测试时还要注意spring.datasource.hikari.maximum-pool-size的默认值是 10，如果并发数超过这个阈值，部分线程会卡在等待连接池归还。

5.2 状态与数据权限

系统里的预约状态用一个枚举承载：BOOKED（已预约）、CANCELLED（已取消）、COMPLETED（已完成）。前端页面在展示状态标签时用了一个过滤器把英文枚举映射成中文文案。这里有个容易被忽略的细节：状态变更时后端必须校验合法流转方向。患者只能把BOOKED状态改成CANCELLED，不能直接把COMPLETED改掉。

往生产方向改造时，可以引入一个简单的状态机设计，使用一个 Map 描述合法转换，Rest 接口在更新状态前先去查映射关系，非法转换直接抛异常。这样比每个状态散落几个 if 判断要清晰得多。

5.3 老版本 Spring Boot 的兼容性

如果你的机器上装的 JDK 版本比较高，比如 JDK 17 甚至 21，这套基于 Spring Boot 2.x 的代码默认是跑不起来的，会报UnsupportedClassVersionError。常见解决思路是装一个 JDK 8 并且配好JAVA_HOME，或者把 Maven 的编译目标改成：

<properties> <maven.compiler.source>17</maven.compiler.source> <maven.compiler.target>17</maven.compiler.target> </properties>

但单纯改 Maven 编译版本并不能让老 Spring Boot 2 兼容新版 JDK，因为 Spring Boot 2.1 及以下版本默认使用的 CGLIB 代理库对高版本 JDK 的支持不完整。稳妥做法还是用 Spring Boot 2.5.6 或 2.7.x 并配合 JDK 8，或者把整套项目升级到 Spring Boot 3.x，但这会引入jakarta命名空间迁移，代价不小。对做毕设的同学来说，优先建议锁 JDK 8。

5.4 第二个实战技巧：预约余号的乐观锁再改良

如果不想在排班接口里用FOR UPDATE的悲观锁，可以在schedule表加一个version字段，更新时使用对应 SQL 条件执行更新操作：

@Modifying @Query("UPDATE Schedule s SET s.remaining = s.remaining - 1, s.version = s.version + 1 " + "WHERE s.id = :id AND s.version = :version AND s.remaining > 0") int deductRemainingWithVersion(@Param("id") Long id, @Param("version") Integer version);

更新返回受影响行数为 0 时，说明当前版本号已过期，Service 层让前端重新获取号源。这种做法在 @Transactional 事务外也能工作，并发性能优于悲观锁，适合单次请求耗时较短的场景。

本文还有配套的精品资源，点击获取