排班问题在每个医院科室里都是月月要经历的折磨。护士长每个月末拿着纸质排班表对着住院人次和护士休假日程反复权衡医生们为了换班在群里来回协调最后排出来的表还是有人不满意。一个基于SpringBootVue的医护人员排班管理系统就是把这些线下博弈搬到线上把排班规则、调班申请、出勤统计全部结构化。对Java开发者和计算机专业毕业生来说这也是一个很好的毕业设计实战项目它覆盖了后端接口开发、前端交互设计、数据库约束建模和权限管理几大模块技术栈不偏门业务场景又比普通的增删改查系统要复杂得多非常适合作为完整项目练手或者论文支撑。这篇文章我会从系统设计思路到数据库建模、从后端排班逻辑到前端交互细节完整拆一套医护人员排班系统是怎么落地实现的。1. 为什么排班是一块硬骨头从医院排班到系统需求的边界做排班系统之前我花了不少时间调研护士长实际是怎么排班的。如果以为排班就是简单地把人塞进班次表里那后面做出来的系统一定废掉了。真实场景里的排班是有很强的业务约束的。1.1 排班系统的特殊性不是普通CRUD普通的管理系统比如图书管理、商品管理核心逻辑就是增删改查。排班系统不一样它要在满足医院运营规律的前提下做资源分配。举个具体例子一个病区一天三班倒白班、小夜、大夜每个班次至少要保证一定数量的在岗护士。你排班的时候必须同时满足几个条件同一个护士一天只能排一个班次同一周内不能连续上超过一定天数的大夜有资质的护士和高年资护士要搭配着排还要照顾护士提交的休假申请。再加上法定节假日、调休安排这个组合约束的复杂程度远超普通的CRUD。所以做这个系统第一步不是写代码而是把排班规则显性化、参数化。我把常见规则分成三类硬性规则同一天一个人不能同时排两个班次病区每天每班次人数必须达标周末和法定节假日的人手不能低于最低值。软性规则尽量避免连续三天以上夜班尽量避免白班后第二天直接跟大夜休假后返岗的第一天尽量不排大夜。人工规则护士长根据科室特殊情况灵活调整比如某位护士怀孕、某天需要去培训、某个特殊病人需要特定护士跟进。系统应该在硬性规则上自动卡死在软性规则上给出提醒和优化建议最后把人工规则留给人来处理。这个定位如果搞错了写出来的排班系统要么管得太死要么管得太松实际用起来都很尴尬。1.2 需求边界划分自动排到哪一步人工兜底到哪一步很多同学做项目的时候喜欢把自动排班这个功能吹得很厉害说系统能一键生成最合理排班表。实际上线之后你会发现完全自动化的排班在医院场景里根本不现实因为它牵涉太多无法量化的因素。我在这个项目里的定位是自动排班负责提供草稿班次分配算法根据上一周期的排班情况在满足硬性约束的前提下自动生成初步排班表护士长在这个基础上做微调调完一键发布。发布时间过后的排班表进入锁定状态普通护士只能查看不能再随意改动。功能边界划分清楚之后整个系统的模块结构就好定了系统管理模块医院科室、用户账号、角色权限、菜单管理。排班管理模块班次定义、排班规则配置、自动生成排班表、手工调整、排班表发布。调班管理模块护士提交换班申请护士长审批审批通过后自动交换班次同时检测是否与已有排班冲突。统计管理模块按科室、按人、按班次类型统计出勤天数、夜班数、调班次数。模块一拆整个项目的工作量和工作边界都清晰了。而且这样拆出来的模块在写论文的时候也特别好论述你不必把重点放在“这个系统能做什么”了而是说清楚“我是怎么解决排班冲突问题、怎么设计调班流程、怎么实现排班统计”的技术点自然就有了深度。2. 技术栈的组合逻辑SpringBootVueMyBatisMySQL各自解决什么问题技术选型这个环节很多人容易犯的毛病是跟风。听说微服务火就上微服务听说Redis热门就强行引入Redis最后项目复杂度上去了但并没有解决任何实际业务问题。排班系统这种典型的中后台业务管理系统技术选型的原则应该是合适、主流、不过度设计。2.1 为什么后端选SpringBoot而不是SSH或者纯ServletSpringBoot现在的地位不用多说。在排班系统里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 UITable组件支持树形数据、固定表头、单元格合并这几个特性在排班表里都很实用。固定表头在排班表滚动时特别好用。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表结构定义成下面这个样子你可以直接参考字段名类型说明idbigint primary key主键user_idbigint医护人员IDschedule_datedate排班日期shift_idbigint班次IDstatustinyint0草稿/1已发布/2已调班/3已作废is_manualtinyint0自动生成/1手动调整remarkvarchar备注说明create_timedatetime创建时间update_timedatetime更新时间需要重点解释的是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. 获取科室护士列表按岗位级别排序 ListUser nurses userMapper.selectByDeptAndRole(deptId); ListUser seniorNurses filterByLevel(nurses, SENIOR); // 3. 按日期遍历按优先级分配班次 ListLocalDate dates getDateRange(startDate, endDate); MapLong, 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里加flushCachetrue强制清缓存。更高频的做法是不要在事务内对同一条数据先查后改再查用修改前的数据对象继续操作逻辑尽量一次查出来后续复用内存里的对象。我最后选择的是第二种方案代码更干净也更好读不依赖MyBatis的缓存参数。6.3 SpringBoot版本太高带来的兼容问题选SpringBoot版本的时候如果一开始选了个特别新的版本号可能会遇到一些烦人的兼容性问题。我在这个项目里遇到过两个一是SpringBoot 3.x 要求JDK17而不少高校机房和部署环境的JDK还是8跑不起来二是新版本里javax.servlet包名改成了jakarta.servlet部分老教程里的代码直接过不了编译。所以在做毕设或项目部署时SpringBoot版本建议用2.7.xJDK用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可以非常方便地支持上述功能。另外如果把排班数据预加载配合前端日历视图排班系统的整体响应速度还可以再上一个台阶。总的来说这个项目表面上是一个管理系统真正做进去你会发现核心的价值在于业务约束的建模能力和复杂逻辑的处理能力。如果你正在准备类似的毕业设计或者开源项目建议把重点排在数据库约束设计、调班事务流程、排班冲突检测这几块上把这几块讲透了答辩或面试时都能体现出扎实的功底。最后想说的是代码能跑通不算结束能扛得住真实业务环境的折腾才是真正做好了。希望这篇拆解能给你一些参考如果你也在做排班或者类似的资源调度系统欢迎一起交流踩坑心得。 
长河君 · 2026/9/17 22:48:45 · 阅读 1.2k 基于SpringBoot+Vue的医护人员排班管理系统设计与实践
排班问题在每个医院科室里都是月月要经历的折磨。护士长每个月末拿着纸质排班表对着住院人次和护士休假日程反复权衡医生们为了换班在群里来回协调最后排出来的表还是有人不满意。一个基于SpringBootVue的医护人员排班管理系统就是把这些线下博弈搬到线上把排班规则、调班申请、出勤统计全部结构化。对Java开发者和计算机专业毕业生来说这也是一个很好的毕业设计实战项目它覆盖了后端接口开发、前端交互设计、数据库约束建模和权限管理几大模块技术栈不偏门业务场景又比普通的增删改查系统要复杂得多非常适合作为完整项目练手或者论文支撑。这篇文章我会从系统设计思路到数据库建模、从后端排班逻辑到前端交互细节完整拆一套医护人员排班系统是怎么落地实现的。1. 为什么排班是一块硬骨头从医院排班到系统需求的边界做排班系统之前我花了不少时间调研护士长实际是怎么排班的。如果以为排班就是简单地把人塞进班次表里那后面做出来的系统一定废掉了。真实场景里的排班是有很强的业务约束的。1.1 排班系统的特殊性不是普通CRUD普通的管理系统比如图书管理、商品管理核心逻辑就是增删改查。排班系统不一样它要在满足医院运营规律的前提下做资源分配。举个具体例子一个病区一天三班倒白班、小夜、大夜每个班次至少要保证一定数量的在岗护士。你排班的时候必须同时满足几个条件同一个护士一天只能排一个班次同一周内不能连续上超过一定天数的大夜有资质的护士和高年资护士要搭配着排还要照顾护士提交的休假申请。再加上法定节假日、调休安排这个组合约束的复杂程度远超普通的CRUD。所以做这个系统第一步不是写代码而是把排班规则显性化、参数化。我把常见规则分成三类硬性规则同一天一个人不能同时排两个班次病区每天每班次人数必须达标周末和法定节假日的人手不能低于最低值。软性规则尽量避免连续三天以上夜班尽量避免白班后第二天直接跟大夜休假后返岗的第一天尽量不排大夜。人工规则护士长根据科室特殊情况灵活调整比如某位护士怀孕、某天需要去培训、某个特殊病人需要特定护士跟进。系统应该在硬性规则上自动卡死在软性规则上给出提醒和优化建议最后把人工规则留给人来处理。这个定位如果搞错了写出来的排班系统要么管得太死要么管得太松实际用起来都很尴尬。1.2 需求边界划分自动排到哪一步人工兜底到哪一步很多同学做项目的时候喜欢把自动排班这个功能吹得很厉害说系统能一键生成最合理排班表。实际上线之后你会发现完全自动化的排班在医院场景里根本不现实因为它牵涉太多无法量化的因素。我在这个项目里的定位是自动排班负责提供草稿班次分配算法根据上一周期的排班情况在满足硬性约束的前提下自动生成初步排班表护士长在这个基础上做微调调完一键发布。发布时间过后的排班表进入锁定状态普通护士只能查看不能再随意改动。功能边界划分清楚之后整个系统的模块结构就好定了系统管理模块医院科室、用户账号、角色权限、菜单管理。排班管理模块班次定义、排班规则配置、自动生成排班表、手工调整、排班表发布。调班管理模块护士提交换班申请护士长审批审批通过后自动交换班次同时检测是否与已有排班冲突。统计管理模块按科室、按人、按班次类型统计出勤天数、夜班数、调班次数。模块一拆整个项目的工作量和工作边界都清晰了。而且这样拆出来的模块在写论文的时候也特别好论述你不必把重点放在“这个系统能做什么”了而是说清楚“我是怎么解决排班冲突问题、怎么设计调班流程、怎么实现排班统计”的技术点自然就有了深度。2. 技术栈的组合逻辑SpringBootVueMyBatisMySQL各自解决什么问题技术选型这个环节很多人容易犯的毛病是跟风。听说微服务火就上微服务听说Redis热门就强行引入Redis最后项目复杂度上去了但并没有解决任何实际业务问题。排班系统这种典型的中后台业务管理系统技术选型的原则应该是合适、主流、不过度设计。2.1 为什么后端选SpringBoot而不是SSH或者纯ServletSpringBoot现在的地位不用多说。在排班系统里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 UITable组件支持树形数据、固定表头、单元格合并这几个特性在排班表里都很实用。固定表头在排班表滚动时特别好用。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表结构定义成下面这个样子你可以直接参考字段名类型说明idbigint primary key主键user_idbigint医护人员IDschedule_datedate排班日期shift_idbigint班次IDstatustinyint0草稿/1已发布/2已调班/3已作废is_manualtinyint0自动生成/1手动调整remarkvarchar备注说明create_timedatetime创建时间update_timedatetime更新时间需要重点解释的是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. 获取科室护士列表按岗位级别排序 ListUser nurses userMapper.selectByDeptAndRole(deptId); ListUser seniorNurses filterByLevel(nurses, SENIOR); // 3. 按日期遍历按优先级分配班次 ListLocalDate dates getDateRange(startDate, endDate); MapLong, 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里加flushCachetrue强制清缓存。更高频的做法是不要在事务内对同一条数据先查后改再查用修改前的数据对象继续操作逻辑尽量一次查出来后续复用内存里的对象。我最后选择的是第二种方案代码更干净也更好读不依赖MyBatis的缓存参数。6.3 SpringBoot版本太高带来的兼容问题选SpringBoot版本的时候如果一开始选了个特别新的版本号可能会遇到一些烦人的兼容性问题。我在这个项目里遇到过两个一是SpringBoot 3.x 要求JDK17而不少高校机房和部署环境的JDK还是8跑不起来二是新版本里javax.servlet包名改成了jakarta.servlet部分老教程里的代码直接过不了编译。所以在做毕设或项目部署时SpringBoot版本建议用2.7.xJDK用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可以非常方便地支持上述功能。另外如果把排班数据预加载配合前端日历视图排班系统的整体响应速度还可以再上一个台阶。总的来说这个项目表面上是一个管理系统真正做进去你会发现核心的价值在于业务约束的建模能力和复杂逻辑的处理能力。如果你正在准备类似的毕业设计或者开源项目建议把重点排在数据库约束设计、调班事务流程、排班冲突检测这几块上把这几块讲透了答辩或面试时都能体现出扎实的功底。最后想说的是代码能跑通不算结束能扛得住真实业务环境的折腾才是真正做好了。希望这篇拆解能给你一些参考如果你也在做排班或者类似的资源调度系统欢迎一起交流踩坑心得。