基于SpringBoot+Vue的医护人员排班管理系统设计与实践

排班问题在每个医院科室里都是月月要经历的折磨。护士长每个月末拿着纸质排班表对着住院人次和护士休假日程反复权衡，医生们为了换班在群里来回协调，最后排出来的表还是有人不满意。一个基于SpringBoot+Vue的医护人员排班管理系统，就是把这些线下博弈搬到线上，把排班规则、调班申请、出勤统计全部结构化。对Java开发者和计算机专业毕业生来说，这也是一个很好的毕业设计实战项目：它覆盖了后端接口开发、前端交互设计、数据库约束建模和权限管理几大模块，技术栈不偏门，业务场景又比普通的增删改查系统要复杂得多，非常适合作为完整项目练手或者论文支撑。

这篇文章我会从系统设计思路到数据库建模、从后端排班逻辑到前端交互细节，完整拆一套医护人员排班系统是怎么落地实现的。

1. 为什么排班是一块硬骨头：从医院排班到系统需求的边界

做排班系统之前，我花了不少时间调研护士长实际是怎么排班的。如果以为排班就是简单地把人塞进班次表里，那后面做出来的系统一定废掉了。真实场景里的排班，是有很强的业务约束的。

1.1 排班系统的特殊性：不是普通CRUD

普通的管理系统，比如图书管理、商品管理，核心逻辑就是增删改查。排班系统不一样，它要在满足医院运营规律的前提下做资源分配。举个具体例子，一个病区一天三班倒，白班、小夜、大夜，每个班次至少要保证一定数量的在岗护士。你排班的时候必须同时满足几个条件：同一个护士一天只能排一个班次；同一周内不能连续上超过一定天数的大夜；有资质的护士和高年资护士要搭配着排；还要照顾护士提交的休假申请。再加上法定节假日、调休安排，这个组合约束的复杂程度远超普通的CRUD。

所以做这个系统，第一步不是写代码，而是把排班规则显性化、参数化。我把常见规则分成三类：

• 硬性规则：同一天一个人不能同时排两个班次；病区每天每班次人数必须达标；周末和法定节假日的人手不能低于最低值。
• 软性规则：尽量避免连续三天以上夜班，尽量避免白班后第二天直接跟大夜，休假后返岗的第一天尽量不排大夜。
• 人工规则：护士长根据科室特殊情况灵活调整，比如某位护士怀孕、某天需要去培训、某个特殊病人需要特定护士跟进。

系统应该在硬性规则上自动卡死，在软性规则上给出提醒和优化建议，最后把人工规则留给人来处理。这个定位如果搞错了，写出来的排班系统要么管得太死，要么管得太松，实际用起来都很尴尬。

1.2 需求边界划分：自动排到哪一步，人工兜底到哪一步

很多同学做项目的时候，喜欢把自动排班这个功能吹得很厉害，说系统能一键生成最合理排班表。实际上线之后你会发现，完全自动化的排班在医院场景里根本不现实，因为它牵涉太多无法量化的因素。我在这个项目里的定位是：自动排班负责提供草稿，班次分配算法根据上一周期的排班情况，在满足硬性约束的前提下自动生成初步排班表，护士长在这个基础上做微调，调完一键发布。发布时间过后的排班表进入锁定状态，普通护士只能查看，不能再随意改动。

功能边界划分清楚之后，整个系统的模块结构就好定了：

• 系统管理模块：医院科室、用户账号、角色权限、菜单管理。
• 排班管理模块：班次定义、排班规则配置、自动生成排班表、手工调整、排班表发布。
• 调班管理模块：护士提交换班申请，护士长审批，审批通过后自动交换班次，同时检测是否与已有排班冲突。
• 统计管理模块：按科室、按人、按班次类型统计出勤天数、夜班数、调班次数。

模块一拆，整个项目的工作量和工作边界都清晰了。而且这样拆出来的模块，在写论文的时候也特别好论述，你不必把重点放在“这个系统能做什么”了，而是说清楚“我是怎么解决排班冲突问题、怎么设计调班流程、怎么实现排班统计”的，技术点自然就有了深度。

2. 技术栈的组合逻辑：SpringBoot+Vue+MyBatis+MySQL各自解决什么问题

技术选型这个环节，很多人容易犯的毛病是跟风。听说微服务火就上微服务，听说Redis热门就强行引入Redis，最后项目复杂度上去了，但并没有解决任何实际业务问题。排班系统这种典型的中后台业务管理系统，技术选型的原则应该是：合适、主流、不过度设计。

2.1 为什么后端选SpringBoot而不是SSH或者纯Servlet

SpringBoot现在的地位不用多说。在排班系统里，SpringBoot有几个实际收益最明显。

第一是自动配置，尤其是数据源和事务管理这一块。排班系统有大量的多表联动操作，比如提交调班申请时，要同时更新排班记录、插入申请记录、记录操作日志，任何一个步骤失败都要整体回滚。SpringBoot配合@Transactional注解，事务边界声明得非常干净。如果是那个年代还在用SSH的老项目，XML配置就有一大堆，调班这种跨表操作管理起来极为痛苦。

第二是快速开发接口用起来顺手。SpringBoot的REST风格接口，配合@RestController、@RequestBody、@RequestParam这些注解，前端后端联调效率很高。排班系统的前端操作很频繁，护士长点一下调整班次、提交发布，都要调用多个接口，接口设计得清晰简约对前后端联调来说太重要了。

第三是内置的Tomcat和Spring生态整合。排班系统有Excel导入导出的需求（很多医院习惯用Excel维护人员信息），SpringBoot直接集成EasyExcel或者POI都很方便；后面如果要引入消息通知，Spring事件机制做模块解耦也成熟。

2.2 Vue在排班场景里的匹配度

前端为什么选Vue而不是React？没有优劣之分，但Vue在国内生态成熟度更高，对后端转前端的人更友好。

排班系统的前端交互有几个难点，恰好Vue处理起来都很顺手。

排班表格的复杂联动是第一个难点。排班表本质上是二维表格：行是人员，列是日期，单元格里是班次。你在一个格子调整班次，可能需要同时影响对应的工时统计、夜班数量汇总、同一天该班次的人数统计。Vue的响应式系统加上计算属性computed，让这种联动变得非常自然，人员排班数据variable一变，统计区域自动刷新。

权限路由控制是第二个难点。排班系统有好几种角色：管理员、护士长、普通护士。管理员管系统和基础数据，护士长管排班、调班审批，普通护士只查看自己的排班、提交调班申请。Vue Router的路由守卫配合动态路由生成，可以根据登录用户的角色动态生成菜单和路由表。普通护士访问排班管理页面，接口和页面双重拦截，这在Vue生态里做起来非常成熟。

还有Vue生态里的Element UI，Table组件支持树形数据、固定表头、单元格合并，这几个特性在排班表里都很实用。固定表头在排班表滚动时特别好用。

2.3 MyBatis在排班数据查询中的不可替代性

MyBatis作为持久层框架，在这类系统中最大的优势是手写SQL灵活。排班系统的查询场景复杂到什么程度呢？你要查某科室某个月每人每班次的数量统计，SQL要写子查询+条件聚合；你要查某个护士是否存在排班冲突，SQL要按人和日期分组统计。MyBatis的XML映射文件支持动态SQL、复杂联合查询，非常适合这种场景。

我举一个实际例子。动态生成排班表的时候，需要根据上一周期某个护士的夜班总数来调整这周她的夜班分配。这个查询就是：先查某人近30天的夜班次数，再根据结果决定是否参与本周的夜班排班。用MyBatis的<choose>动态标签，可以在一段SQL里根据传入参数动态拼接不同的查询条件，不用像JPA那样为了兼容各种查询条件写一堆方法名。

自动生成排班表时需要按科室、按班次统计在岗人数，这个用了MyBatis的GROUP BY加条件查询，直接返回一个统计Map，后端拿到数据后做逻辑判断，整体流程很清晰。

MySQL作为底层数据库，在这个场景里也没问题。排班系统的数据量级不是很大（二级医院全院数据也就几千人，一个病区几十人居多），MySQL的InnoDB引擎支持事务和外键约束，足够满足排班系统的需求。内存和磁盘开销也低，部署简单。

3. 数据库设计：排班系统的核心约束都写进表结构

排班系统的数据库设计是整个项目的灵魂。表结构如果设计得合理，很多业务逻辑的实现会很顺畅；表结构如果设计得草率，后面写排班冲突检测的时候会怀疑人生。

3.1 核心表结构拆解

先说说我做这张表时的思考过程。班次表其实不只是存一个“白班”“夜班”的名字，它还包含班次的起止时间、时长、班次颜色标识等。在排班视图里开发人员通常会给不同班次标定不同颜色，方便护士长一眼识别，这个颜色就可以存在shift_color字段里。

排班表是这个系统的核心表，它记录的是“某人在某天是什么班”。

设计时必须包含几个关键字段：

• user_id，关联用户表，表示这个排班记录属于谁。
• schedule_date，排班日期。
• shift_id，关联班次表，表示这个人在这一天是什么班。
• schedule_type，排班状态：草稿、已发布、已调班、已失效。
• period_id，周期标识，表示属于哪一期的排班周期。

这三个字段联合起来，就能支持排班冲突检测的核心查询。查询开始时，检查同一个user_id在同一个schedule_date是否已经存在记录，如果有，就是冲突。这就是最基础的硬性约束，靠数据库唯一索引可以兜底。

3.2 唯一索引是最后一道防线

数据库设计阶段很重要的一件事，是给可能产生冲突的表建唯一索引。

排班表tb_schedule里给(user_id, schedule_date)建唯一索引，表示一个人一天只能有一条排班记录。调班申请合并到排班表时，如果两个人交换班次，事务第二步是同时修改两个人的记录，如果某个人在目标日期已经有了排班，唯一索引会直接报错，事务回滚，天然防冲突。

还有调班申请表。我建的是(from_user_id, to_user_id, apply_date, status)的唯一索引，防止同一组人同一天重复提交换班申请。这个索引在测试的时候还救过我一次，两边同时提交申请，如果后端没有加防重处理，数据库的这条唯一索引就是最后防线。

我在实际开发中把tb_schedule表结构定义成下面这个样子，你可以直接参考：

需要重点解释的是is_manual字段。自动排班生成的记录和手工调整的记录有本质区别：手工调整的记录，在再次自动生成排班草稿时不应该被覆盖。这个字段就是用来区分记录的来源，自动生成时跳过已手动标记的记录。这个是实际在使用中总结出来的坑，第一次开发往往容易忽略。

3.3 统计指标的冗余设计

排班系统绕不开统计报表。每个月底护士长要看：某人这个月上了几个白班、几个夜班、调了几次班、休假几天。如果这些统计全部依赖每次实时查排班表聚合，数据量小的时候没问题，但到了月末统计高峰期，复杂聚合SQL加上前端多次请求，性能就会明显下滑。

我的方案是在人员统计表tb_user_shift_statistic里按月冗余累计数据。每个月自动生成排班表后，后台跑一次批量统计，把结果写入统计表。护士长打开统计页面时，直接查统计表，数据秒开。前端展示用ECharts画柱状图和饼图，数据丰富度也好很多。

统计表里保留了什么字段呢？包括统计月份、用户ID、科室ID、白班计数、夜班计数、小夜计数、调班计数、缺勤计数。这些字段在月底导出Excel时直接映射列，一行代码都不用多写。

具体SQL倒是很简单：

SELECT user_id, MONTH(schedule_date) AS mn, COUNT(*) AS total_days, SUM(CASE WHEN shift_type = 'NIGHT' THEN 1 ELSE 0 END) AS night_count FROM tb_schedule WHERE schedule_date BETWEEN #{startDate} AND #{endDate} AND status = 1 GROUP BY user_id, MONTH(schedule_date);

3.4 数据一致性与外键策略

后端开发里用外键的比例越来越少。排班系统中涉及多个表之间的关联，如果用外键硬性约束，每次插入数据都要检查关联表，性能会打折。而且排班系统有些记录是历史归档数据——比如某护士调到别的科室了，月份统计表里不应该因为外键约束就拒绝写入。所以我只建索引不建外键，表之间的关联关系由Service层代码控制。

但是要注意，删除数据的时候必须代码层面检查。比如删除一个班次类型时，要先查tb_schedule里是否还有使用这个班次类型的排班记录，如果有就不能删，必须把这些记录改到替代班次或先处理掉。这类逻辑写在Service层，配合事务控制，比外键更灵活。

4. 后端排班逻辑的实现：从轮转模板到冲突检测

排班系统的后端是整个系统的大脑，粗看起来是增删改查，真正打动人的地方在于排班表的自动生成策略和冲突检测方案设计。这两块逻辑写明白，项目才有真正的技术含量。

4.1 自动排班的算法选择

自动排班算法是排班系统的灵魂。我在这个项目里用的是规则优先级+贪心分配策略。

先把科室里所有护士的信息拉回来，根据护士的岗位级别分组。主管护师、护师、护士是需要分开处理的，因为每个班次对人员资历有要求——大夜班至少要有一名主管护师带班。

然后按班次类型的优先级依次分配：大夜班优先分配，因为大夜对人手和资历要求最高、最紧缺；接着是小夜班、白班、行政班。最后把剩下的护士填入调休、学习、休假等。

这样设计的原因很直接：紧缺资源先分配，后面的弹性空间最大。如果先排白班，把人都排得差不多了，后面发现大夜缺人，调整成本就高很多。

每条排班记录写入前都要做冲突校验：

• 同一个护士同一天是否存在已有排班。
• 是否已经达到该护士本月夜班数量上限。
• 护士是否在休假名单内。
• 同一天该班次是否已经达到人数上限。

校验通过才写入数据库。校验失败则跳过，穷举处理完毕再检查是否所有人都被安排了。如果还有未安排的，就调用后端接口将相关人员列出，提示护士长手动处理。这个设计思路的合理性很清晰——把机器能自动解决的大部分计算都省略掉了，剩下的人性化决策留给人。

4.2 核心方法实现：自动生成排班表

后端核心接口的逻辑围绕名SchedulingService展开，核心方法大概是这样的：

@Override @Transactional(rollbackFor = Exception.class) public boolean autoSchedule(Long deptId, String startDate, String endDate) { // 1. 清理该周期内非手动调整的排班记录 scheduleMapper.deleteAutoSchedule(deptId, startDate, endDate); // 2. 获取科室护士列表，按岗位级别排序 List<User> nurses = userMapper.selectByDeptAndRole(deptId); List<User> seniorNurses = filterByLevel(nurses, "SENIOR"); // 3. 按日期遍历，按优先级分配班次 List<LocalDate> dates = getDateRange(startDate, endDate); Map<Long, Integer> nightCountMap = new HashMap<>(); for (LocalDate date : dates) { // 先排NIGHT班 for (User nurse : seniorNurses) { if (canAssign(nurse, date, "NIGHT", nightCountMap)) { insertSchedule(nurse.getId(), date, nightShiftId); nightCountMap.merge(nurse.getId(), 1, Integer::sum); } } // 再排DAY班和EVENING班，逻辑类似，省略 } // 4. 检查未排班人员并返回前端提示 return true; }

canAssign方法的逻辑要写清楚，它检查四个方面：这个人今天是否已经排过班，这个月夜班是否排满了上限，这个人是否在休假/请假状态里，这个班次的人数是否已满。

deleteAutoSchedule一开始我做得比较激进，直接清空整个周期内所有排班记录，后来发现不对——护士长之前手动调过的班会被自动清掉。后来改成只清理is_manual = 0的记录，这样保留了人工微调的成果。这个细节是实际使用中总结出来的，不做这个区分的话系统会被护士长骂死。

4.3 调班/换班的事务边界设计

调班流程是排班系统里使用频率很高的体验之一。护士A和护士B要互换某一天的班次，流程是这样：A发起申请，选择自己某一天的班次和目标班次，目标班次属于B且在B名下，提交给护士长审批。护士长审批通过后，系统交换两个人的班次。

这个流程的事务边界值得仔细思考。调班申请记录和实际换班执行，最好是分两个阶段。申请阶段只往调班申请表里插入一条记录，状态设为待审批；审批阶段在事务里执行换班动作。审批阶段的所有数据库操作都要在一个事务里：更新原排班记录A的状态为已调班、更新B的状态为已调班、分别插入两条交换后的排班记录、更新调班申请状态为已通过、记录调班日志。

如果只做成一个阶段，在事务里同时处理申请和换班，一旦换班过程中遇到冲突，申请记录也会跟着回滚，用户无法知道曾经提交过申请。分成两阶段的好处是：冲突发生时用户看到的是“审批失败”，申请状态变为审批失败，而不是整个申请凭空消失。

再一个容易踩坑的地方是：换班的时候只考虑了目标排班是否为空，没有考虑换班后这个人这个月的班次总数是否发生变化。举个例子，A本来是白班，B是大夜，互换后A多了一个大夜，B少了一个大夜，那么本月夜班次数统计就变了。如果A已经上了很多大夜，这次换班会让他夜班次数超标。所以审批阶段的事务里，除了交换记录，还要重新计算两个人的月度夜班统计，发现超标就拒绝。这一个点我在最初几版里没有考虑，还是护士长用了一周后在反馈里发现的。

调班的核心逻辑如下：

@Transactional(rollbackFor = Exception.class) public boolean approveSwap(Long applyId) { SwapApply apply = swapMapper.findById(applyId); // 1. 校验两条排班记录是否仍然有效 Schedule scheduleA = scheduleMapper.findByUserAndDate(apply.getFromUserId(), apply.getFromDate()); Schedule scheduleB = scheduleMapper.findByUserAndDate(apply.getToUserId(), apply.getToDate()); if (scheduleA == null || scheduleB == null) { throw new RuntimeException("排班记录不存在或已变更"); } // 2. 目标日期冲突校验 if (scheduleMapper.existsByUserAndDate(apply.getFromUserId(), apply.getToDate())) { throw new RuntimeException("对方日期已有排班"); } if (scheduleMapper.existsByUserAndDate(apply.getToUserId(), apply.getFromDate())) { throw new RuntimeException("您的日期已有排班"); } // 3. 更新原记录状态 scheduleA.setStatus(3); scheduleB.setStatus(3); scheduleMapper.updateById(scheduleA); scheduleMapper.updateById(scheduleB); // 4. 插入新的排班记录 Schedule newA = new Schedule(); newA.setUserId(apply.getFromUserId()); newA.setScheduleDate(apply.getToDate()); newA.setShiftId(scheduleB.getShiftId()); newA.setStatus(0); scheduleMapper.insert(newA); Schedule newB = new Schedule(); newB.setUserId(apply.getToUserId()); newB.setScheduleDate(apply.getFromDate()); newB.setShiftId(scheduleA.getShiftId()); newB.setStatus(0); scheduleMapper.insert(newB); // 5. 更新申请状态 apply.setStatus(1); swapMapper.updateById(apply); return true; }

这里有个容易忽略的问题：新插入的两条排班记录的status应该设为0还是1？我设置为0表示草稿，因为审批通过后护士长可能需要再校对一版。如果直接设为已发布状态，那么护士端小程序看到排班表突然变了，但没有经过二次确认，体验上容易出问题。发布动作由护士长在页面上主动点击完成，系统会推送通知给相关护士。

5. 前端交互设计与几个容易翻车的地方

排班系统的前端页面，我不打算再去罗列每个页面怎么搭了。这里重点说说排班系统里比较有代表性的两个交互难点，和Vue开发中比较容易翻车的地方。

5.1 排班表格的渲染与性能优化

排班主体页面是一个人员×日期的二维表格。人员50人，日期30天，单元格就是1500个。如果每个单元格里都放着班次标签、下拉选择框、人数统计气泡，不做任何处理直接渲染，卡顿是必然的。

我在项目里采用的是Element UI的el-table，开启virtual-scroll虚拟滚动。这个组件在大数据量场景下，只渲染可视区域内的DOM节点，表格滚动的流畅度提升非常明显。之前实测1500个单元格的表格，直接渲染需要1.2秒，开启虚拟滚动后缩短到300毫秒左右。

单元格内使用label的点击编辑功能，配一个v-if控制的下拉选择框。默认状态下显示span，点击时切到编辑状态显示下拉框，选择完自动保存。这种交互比每次编辑都跳转页面或者弹窗要轻量得多，但要注意控制当前正在编辑的单元格ID，避免多个单元格同时进入编辑状态导致数据混乱。做法是在data里维护一个editingCell变量，记录当前正在编辑的单元格坐标，点击别处时自动关闭。

5.2 日历视图与状态展示

除了表格视图，我还做了日历视图给普通护士用。护士登录后，首页展示当月日历，日历里的每一天显示当天的班次名称和班次颜色。这个视图的视觉可读性比表格要好很多，护士用起来更直观。

日历组件是在Element UI的el-calendar基础上封装的。el-calendar支持自定义日期单元格内容，我在里面调接口拿到当月排班数据，按日期分组存储，渲染时直接映射。打开时默认展开为月视图，每天下面的小圆点颜色代表不同班次（红色是大夜，黄色是小夜，蓝色是白班），一眼能看清自己这个月的班型分布。箭头切换上下月后会触发日期区间变化事件，重新请求数据，无缝衔接。

5.3 Vue路由懒加载与打包后的坑

前端打包上传之后，发现首屏加载时间变得很长。排查原因是在router里全部静态引入了Page组件，打包后的app.js体积庞大。后来把路由改成懒加载方式引入：

component: () => import('@/views/schedule/ScheduleList.vue')

改成懒加载后，首屏体积从2MB降到了600KB左右，加载速度快了很多。但这带来一个新的问题：懒加载会按路由拆分chunk，如果拆得太碎，小文件多到服务器请求也费时间。我最终用了一个折中的策略：按模块拆chunk，四个核心页面放在同一个chunk里，统计数据单独拆，登录页单独拆，这样既能保证首屏速度，又不会产生过多的小请求。

5.4 权限路由管理

前端权限这块用的是动态路由的实现方式：后端登录接口返回用户信息和角色标识，前端根据角色生成对应的路由和菜单列表。

在Vue Router里，初始化路由只注册login和404，登录成功后根据当前用户的权限点列表（后端返回的permission codes）过滤出有权限的路由，再调用router.addRoute动态注册。这种方式比把所有路由一次性注册然后靠meta字段控制show/hide要彻底得多——没有权限的路由根本不存在于路由表里，通过URL直接访问会被404兜底拦截。

后端也要做相应的权限校验，Controller层使用Spring Security配合注解检查权限。排班管理相关接口标注hasRole('NURSE_MANAGER')，普通护士的接口只有hasRole('NURSE')。这样做前后端双重校验，安全性比较稳。

6. 联调、部署与几个印象深刻的坑

这个系统从开发到部署，经历了反复debug的过程，踩过几个比较有代表性的坑，正好把坑写出来，给后面做类似项目的同学做个参考。

6.1 跨域配置不是只加一个注解那么简单

前后端分离的项目，跨域问题几乎必踩。开发调试阶段，Vue跑在8080端口，SpringBoot跑在8088端口，请求直接跨域。当时我在后端写了个全局跨域配置类，实现了WebMvcConfigurer接口统一注入跨域配置，看起来没什么问题：

@Configuration public class CorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/**") .allowedOriginPatterns("*") .allowedMethods("*") .allowedHeaders("*") .allowCredentials(true) .maxAge(3600); } }

但实际联调时发现部分接口还是报跨域错误。最终定位到问题原因是Spring Security的过滤器链先于CORS配置生效，导致预检请求（OPTIONS请求）被拦截。解决办法是在Spring Security的配置里放行OPTIONS请求，并在安全过滤链中显式添加CorsFilter。这个顺序问题在前后端分离项目中很常见，建议大家在排查时先想一想请求是在哪一层被拦下来的。

6.2 MyBatis缓存导致的关联查询脏数据

这是一个让人印象深刻的问题。调班审批通过后，排班数据已经更新了，但前端页面刷新后看到的还是旧数据。一开始以为是缓存配置问题，排查后发现是MyBatis一级缓存和Spring的@Transactional一起造成的。

看下面的代码：

@Transactional public boolean approveSwap(Long applyId) { // 第一次查询A的排班记录，写入一级缓存 Schedule s1 = scheduleMapper.findByUserAndDate(fromUserId, fromDate); // 更新了记录A scheduleMapper.updateById(s1); // 第二次查询，可能走缓存，拿到的是更新前的数据 Schedule s2 = scheduleMapper.findByUserAndDate(fromUserId, fromDate); // 导致后续逻辑用了旧数据！ }

MyBatis一级缓存是会话级别的，同一个SqlSession内第二次执行完全相同的SQL时，如果开启了本地缓存，会直接返回缓存数据。在Spring里，一次事务往往复用同一个SqlSession，所以这个坑很容易踩到。解决办法有两个：

• 在需要实时查询的方法上，Mapper方法的statement里加flushCache="true"，强制清缓存。
• 更高频的做法是不要在事务内对同一条数据先查后改再查，用修改前的数据对象继续操作，逻辑尽量一次查出来，后续复用内存里的对象。

我最后选择的是第二种方案，代码更干净也更好读，不依赖MyBatis的缓存参数。

6.3 SpringBoot版本太高带来的兼容问题

选SpringBoot版本的时候，如果一开始选了个特别新的版本号，可能会遇到一些烦人的兼容性问题。我在这个项目里遇到过两个：一是SpringBoot 3.x 要求JDK17，而不少高校机房和部署环境的JDK还是8，跑不起来；二是新版本里javax.servlet包名改成了jakarta.servlet，部分老教程里的代码直接过不了编译。

所以在做毕设或项目部署时，SpringBoot版本建议用2.7.x，JDK用8或者11，配合MyBatis starter用2.x版本，整体兼容性就非常稳，网上遇到问题的概率也低得多。这不是说新版本不好，而是在做交付式项目时，稳定性和别人复现的便利性优先。

6.4 Vue打包后布局异常

这个在热词里也看到了。开发环境跑得好好的，npm run build部署到服务器后，页面打开发现样式乱掉或者图片加载不出来。

这种问题基本都是静态资源路径问题导致的。Vue默认的publicPath是根目录/，但如果你把前端项目部署在一个子路径下，比如http://xxx:8080/hospital/，那么所有静态资源都会去根目录找，自然找不到。

修改方式很简单。Vue绑定环境变量设在vue.config.js里：

module.exports = { publicPath: process.env.NODE_ENV === 'production' ? '/hospital/' : '/' }

或者直接用相对路径：publicPath: './'。不过相对路径在路由开启history模式时会有问题，建议部署时统一用一个子路径，不要混用。这个问题当时排查了很久才发现，因为开发环境和生产环境的路径策略不一样。

6.5 事务不生效的一个隐性原因

事务这块我也遇到过一个问题。网上的说法很经典：SpringBoot事务不生效，最常见的几个原因是类没有被Spring管理、方法不是public、自调用绕过代理。我当时在调班审批Service里，自己写了一个私有方法，在私有方法里原生调用了同类里的另一个事务方法，结果事务就没生效。原因是Spring的@Transactional基于代理机制，同类内部调用不会走代理，事务注解被跳过了。

后来把内部调用拆到另一个Service类中，或直接把事务注解加在对外的方法上，问题就解决了。这个问题在初学SpringBoot时特别容易犯，调班审批这种地方恰恰是数据一致性要求最高的环节，事务失效会导致数据错乱，后果严重。

7. 这套系统还能怎么扩展延伸

排班系统做到能上线运行，满足了护士长日常排班和全院统计的基础需求，基本算是一个可交付的项目了。但如果想让它在技术深度上再往前走一步，后面还有几个方向值得探索。

7.1 排班算法从贪心到最优化

当前用的是贪心策略：优先排紧缺班次、优先满足硬性约束、按人员资历逐层分配。这种方式最大的问题是贪心容易陷入局部最优解。比如前面先满足了某个科室的白班需求，结果后面大夜排班时发现资历合适的护士不够用了。

如果要提升自动化程度，可以引入利用约束求解的求解器或规划引擎，它可以把排班问题形式化为硬性约束和软性约束的组合，然后通过求解器找到全局最优解。比如OptaPlanner，或者国内不少项目在用的QLExpress配合自研回溯算法。这个改造的成本不低，但对于自动排班复杂的场景，收益相当明显。

7.2 集成企业微信/钉钉的通知能力

排班表发布、调班审批结果这类消息，目前是站内通知，护士得主动登录系统查看。实际使用中，消息触达效率不高。后续可以集成企业微信或者钉钉的机器人Webhook，排班表发布后自动推送到科室群，审批通过/拒绝也实时推送。

Webhook集成本身不复杂，RestTemplate发一个POST请求的事，但带来的使用体验提升非常明显。护士不用频繁打开系统刷消息，日程安排直接在手机消息里就能看到。

7.3 Redis缓存热数据与排班表实时预览

排班表的查询频率很高，尤其是月底统计和发布前后的预览。可以把已经生成的排班草稿缓存到Redis里，以科室+周期为key，排班数据JSON序列化后存储。护士长调整某个班次时，先更新Redis数据再异步落库，这样前端预览时基本无延迟。

同时，基于SpringCache可以非常方便地支持上述功能。另外，如果把排班数据预加载配合前端日历视图，排班系统的整体响应速度还可以再上一个台阶。

总的来说，这个项目表面上是一个管理系统，真正做进去你会发现，核心的价值在于业务约束的建模能力和复杂逻辑的处理能力。如果你正在准备类似的毕业设计或者开源项目，建议把重点排在数据库约束设计、调班事务流程、排班冲突检测这几块上，把这几块讲透了，答辩或面试时都能体现出扎实的功底。最后想说的是，代码能跑通不算结束，能扛得住真实业务环境的折腾才是真正做好了。希望这篇拆解能给你一些参考，如果你也在做排班或者类似的资源调度系统，欢迎一起交流踩坑心得。