医生排班与患者预约系统核心实现：从数据库设计到并发控制

先聊一个很常见的场景：医院门诊大厅里，患者早上七点就排到窗口，结果被告知今天坐诊的医生临时调班了；另一边，科室排班表还是靠手工Excel维护，导诊护士每周都要花半天时间核对哪个医生撞了时间段。这套“医生排班与患者预约管理系统”的核心目标，就是把医生的出诊安排和患者的预约挂号真正串起来，让医院服务台不再靠人肉排班，让患者在手机上就能提前看到三天后某个科室还有哪些号。作为一套完整的毕设项目源码（资源编号48628），它覆盖了信息管理、排班规则、预约流程、并发控制和前后端交互的完整链路，非常适合正在准备课设、毕设，或者想了解医疗业务系统怎么落地开发的读者参考。

我实际带过好几套类似的项目，最大的感受是：这个题目看上去不大，但做得深入之后会发现，它比很多“电商管理系统”“图书管理系统”要复杂得多，因为排班和预约背后全是规则约束和状态流转，随便一个环节没想清楚，演示的时候就会翻车。接下来我把这套项目的设计思路、数据库结构、核心实现和踩坑记录完整拆开，逐段讲清楚。

1. 项目立意与整体设计思路

1.1 为什么选“医生排班+患者预约”这个题

很多同学选毕设题目，容易走两个极端：一是选得太简单，比如做一个单表的CRUD系统，答辩时老师随便问两句就没什么可讲的了；二是选得太复杂，比如做AI辅助诊断、大数据分析平台，结果开发周期拖到半年还完不成核心功能。

“医生排班与患者预约”刚好卡在中间，是一个难得的“麻雀虽小五脏俱全”的题目。它的业务完整度非常适中：涉及管理员、医生、患者三种角色，有排班规则校验、号源数量控制、预约状态流转、时间冲突检测、权限隔离这些真实业务场景，还有队并发锁的处理。这些点拿出来任何一个，都能在答辩时拆开讲上几分钟，而且都有具体的代码落地支撑，不是空谈。

更重要的是，这个题目贴近真实的行业需求。医疗信息化是这几年持续发力的方向，预约挂号、分时段就诊已经是很多医院的标配。做了这个项目，你在简历上写“了解医疗业务场景，熟悉预约挂号与排班管理的数据模型设计”，是有实际项目背书的，比写“熟悉XX管理系统”有含金量得多。

1.2 系统整体规划：角色、流程与功能地图

在动手写代码之前，一定要先把业务流程画清楚。这套系统的核心流程可以归结为一条主线：管理员维护基础数据（科室、诊室、医生信息）-> 医生或管理员配置排班规则 -> 系统按规则生成具体排班计划 -> 患者浏览号源并提交预约 -> 系统锁定号源 -> 患者按时就诊 -> 医生或前台完成核销 -> 事后统计复盘。

围绕这条主线，系统主要分三类角色：

• 管理员：负责维护医生档案、科室和诊室信息，审核排班计划，查看全院的预约数据，处理临时调班和停诊。
• 医生：查看自己的排班日历，确认出诊计划，查看当天预约患者的列表，完成就诊状态更新。
• 患者：注册登录后按科室、日期、医生检索号源，选择时间段完成预约，查看预约记录，必要时取消预约。

功能模块按职责划分，大致是下面这张表：

单看功能列表，这套系统并没有堆很多花哨的页面，但胜在业务流程是完整闭环的。从医生维护排班，到患者完成预约，到最后管理员统计出诊与预约数据，一条线走通，数据有来龙去脉，这才是导师愿意看的东西。

1.3 技术选型背后的关键考量

技术栈的选择上，我比较推荐最稳妥的组合：后端用Java Spring Boot + MyBatis Plus，前端用Vue 3 + Element Plus，数据库用MySQL，鉴权用Sa-Token或者Spring Security。如果前端基础比较弱，也可以直接用Spring Boot的Thymeleaf模板引擎做服务端渲染，少写一些前后端联调的代码，把精力集中在业务逻辑上。

选这套组合的理由很简单：生态成熟、资料多、踩坑少。Spring Boot在社区里的解决方案一搜一大把，MyBatis Plus能省掉大量单表的CRUD代码，Vue配Element Plus做管理后台的表格、表单、日历组件都能直接复用。作为一个毕设，稳定性比技术新颖度重要得多。

还有一个容易被忽略的点：项目要能在自己的电脑上跑起来，并且打包部署步骤越简单越好。有些同学一上来就上微服务、消息队列、Elasticsearch，结果光搭环境就花了两周，最后项目没法演示，得不偿失。毕设不是生产系统，围绕核心业务把每个环节做扎实，比堆中间件更能体现能力。

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

2.1 核心数据模型：从排班到预约如何串联

很多人做这类系统，栽就栽在表关系没想清楚。排班和预约不是两张独立的表，它们之间必须用“号源”这个概念串起来。

最简单的业务模型是这样的：一个科室里，一个医生在一个时间段坐诊，产生一个排班记录。这个排班记录对应N个号源，患者预约时，实际上是占用这个排班下的某一个号源。所以数据库里的核心表至少有五张：科室表、医生表、医生出诊规则表（排班模板）、排班计划表（实际生成的某天某时段出诊记录）、预约记录表。

排班计划表里的每一条记录，可以理解为“2025年6月10日上午，心内科，某医生，普通门诊，放号30个”。而预约记录表里的每一条记录，则指向这个排班，并锁定其中一个号。这样设计的好处是：所有业务逻辑都能集中在排班计划和预约记录这两张表上展开，查询、统计、冲突检测都有清晰的数据入口。

2.2 关键表字段设计与建表要点

下面我给出几张核心表的简化建表语句，并说明关键字段的设置意图。

科室表：

CREATE TABLE `department` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `dept_name` varchar(50) NOT NULL COMMENT '科室名称', `dept_code` varchar(20) NOT NULL COMMENT '科室编码', `status` tinyint(1) NOT NULL DEFAULT '1' COMMENT '1启用 0停用', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_dept_code` (`dept_code`) ) ENGINE=InnoDB COMMENT='科室表';

医生表：

CREATE TABLE `doctor` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `dept_id` bigint(20) NOT NULL COMMENT '所属科室', `doctor_name` varchar(50) NOT NULL COMMENT '姓名', `title` varchar(20) DEFAULT NULL COMMENT '职称:主任医师/副主任医师/主治医师', `intro` varchar(500) DEFAULT NULL COMMENT '简介', `status` tinyint(1) NOT NULL DEFAULT '1' COMMENT '1在岗 0停诊', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_dept_id` (`dept_id`) ) ENGINE=InnoDB COMMENT='医生表';

排班计划表：

CREATE TABLE `schedule` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `doctor_id` bigint(20) NOT NULL COMMENT '医生ID', `dept_id` bigint(20) NOT NULL COMMENT '科室ID', `schedule_date` date NOT NULL COMMENT '出诊日期', `period` tinyint(1) NOT NULL COMMENT '1上午 2下午 3夜班', `room_no` varchar(20) DEFAULT NULL COMMENT '诊室号', `total_slots` int(11) NOT NULL DEFAULT '30' COMMENT '总号源数', `booked_slots` int(11) NOT NULL DEFAULT '0' COMMENT '已预约数', `schedule_type` tinyint(1) NOT NULL DEFAULT '1' COMMENT '1普通 2专家 3特需', `status` tinyint(1) NOT NULL DEFAULT '1' COMMENT '1正常 2停诊 3已结束', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_doctor_date_period` (`doctor_id`, `schedule_date`, `period`), KEY `idx_date_dept` (`schedule_date`, `dept_id`) ) ENGINE=InnoDB COMMENT='排班计划表';

预约记录表：

CREATE TABLE `appointment` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `schedule_id` bigint(20) NOT NULL COMMENT '排班ID', `patient_id` bigint(20) NOT NULL COMMENT '患者ID', `appoint_code` varchar(32) NOT NULL COMMENT '预约流水号', `status` tinyint(1) NOT NULL DEFAULT '0' COMMENT '0待支付/锁定 1已确认 2已完成 3已取消 4已爽约', `lock_expire_time` datetime DEFAULT NULL COMMENT '锁定到期时间', `visit_no` int(11) DEFAULT NULL COMMENT '就诊序号', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, `update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_appoint_code` (`appoint_code`), UNIQUE KEY `uk_schedule_patient` (`schedule_id`, `patient_id`), KEY `idx_patient_id` (`patient_id`) ) ENGINE=InnoDB COMMENT='预约记录表';

这里有几个字段值得特别说明：

• schedule表上的唯一索引uk_doctor_date_period用来保证同一个医生同一天同一个时段只能有一条排班记录，这是防止排班冲突的第一道防线。
• booked_slots字段不是冗余，它是预约并发控制的关键，每次预约操作都需要比对它跟total_slots的关系。
• appointment表上的uk_schedule_patient防止同一个患者对同一个排班重复预约，这在生产环境里也是必须的约束。
• status字段用数字枚举而不是字符串，查询效率更高，也方便Java端用枚举类映射。

3. 核心功能实现与实操记录

3.1 医生排班生成逻辑：模板与冲突检测

排班是这套系统最有“业务味道”的部分。如果做成管理员每天手动选择医生和时间段，功能虽然能跑，但答辩时导师只要问一句“医生请假了怎么办，第二天排班要怎么重排”，你的设计就会暴露短板。所以实际的实现思路应该是：先有排班规则模板，再按日期自动批量生成排班计划。

排班模板表记录的是比如“某医生每周一上午出诊，放号40，普通门诊，诊室201”。生成排班时，系统从起始日期到结束日期逐日遍历，判断当天是星期几，然后去匹配模板，匹配上的就生成一条schedule记录。生成的逻辑不复杂，核心在如何高效检测冲突：

// 伪代码：检测同一医生同一时段是否已有排班 int count = scheduleMapper.selectCount( new LambdaQueryWrapper<Schedule>() .eq(Schedule::getDoctorId, doctorId) .eq(Schedule::getScheduleDate, date) .eq(Schedule::getPeriod, period) ); if (count > 0) { throw new BizException("该医生在当天此时段已有排班，请勿重复生成"); }

这里选用了数据库唯一索引加预查询的双重保障：预查询提前给出友好提示，唯一索引兜底防止并发插入时产生脏数据。排班生成跑完后，还可以加一个“全量冲突检测”的定时任务，扫描当前所有未结束排班，找出医生跨科室重复出诊、同一诊室同一时段超员这类特殊情况，供管理员确认。

3.2 患者预约主流程：从选号到锁定号源

预约流程是整条链路上最核心的部分，它最大的难点在于“号源是稀缺资源”，不能被超卖。我推荐的实现方式是“预占+超时释放”：患者点击预约时，系统不立即把预约状态置为确认，而是先锁定号源，给一个默认十五分钟的支付或确认等待期。超过十五分钟未完成确认，锁自动解除，号源回流给其他患者。

具体实现上，预约接口的事务逻辑是这样的：

@Transactional(rollbackFor = Exception.class) public Long createAppointment(CreateAppointmentBody body) { // 1. 锁定排班记录，防止并发超售 Schedule schedule = scheduleMapper.selectForUpdate(body.getScheduleId()); if (schedule == null) { throw new BizException("排班不存在"); } if (schedule.getStatus() != 1) { throw new BizException("当前排班状态不可预约"); } if (schedule.getBookedSlots() >= schedule.getTotalSlots()) { throw new BizException("号源已约满"); } // 2. 检查患者是否已有该排班的预约 Long exists = appointmentMapper.selectCount(...); if (exists > 0) { throw new BizException("您已预约过该时段，请勿重复操作"); } // 3. 生成预约记录，初始状态为锁定 Appointment appointment = new Appointment(); appointment.setScheduleId(schedule.getId()); appointment.setPatientId(body.getPatientId()); appointment.setStatus(0); appointment.setLockExpireTime(LocalDateTime.now().plusMinutes(15)); appointment.setVisitNo(schedule.getBookedSlots() + 1); // 就诊序号 appointmentMapper.insert(appointment); // 4. 排班已约数加1 scheduleMapper.increaseBookedSlots(schedule.getId()); return appointment.getId(); }

注意selectForUpdate这一步，它会对schedule表的这一行加悲观锁。在同一时刻有多个患者抢同一个排班的号时，数据库会让这些请求排队执行，后到的请求拿到的booked_slots已经是前一个事务更新后的值，从而避免超售。有的同学喜欢用乐观锁，在schedule表加version字段，配合update ... where booked_slots < total_slots也能解决，但会在代码里多一层重试处理。对于毕设项目，悲观锁的思路更直观，也更容易向答辩老师解释。

3.3 并发与权限控制的三处细节

预约系统的高并发场景，精髓全在细节里。第一个细节是预约状态的流转时机。前面提到的状态枚举0锁定 1已确认 2已完成 3已取消 4已爽约，在代码里要对应一个状态机，不是任何状态都能跳到任何状态：

• 锁定状态可以取消，也可以确认支付。
• 确认支付后，只能进入已完成或已取消（限就诊前）。
• 超过就诊时间未到的，由系统定时任务批量标记为爽约。

第二处是权限控制。管理员、医生、患者三个角色，接口必须严格隔离。比如普通患者不能调用“创建排班”的接口，医生不能调用“修改排班模板”的接口。我建议用注解式的权限校验，比如自定义一个@RequireRole("ADMIN")注解，配合拦截器统一校验，避免在Controller里写一堆重复的if判断。

第三处是数据权限。医生登录后查看预约患者列表，只能看到属于自己科室和自己排班的数据，不能看到全院数据。这个必须使用doctor_id作为过滤维度，而不是简单地在查询条件里拼一个status = 1就完事。就这一条设计，答辩时很多老师会追问，做好了就是亮点。

4. 踩坑实录与排查技巧

4.1 排班冲突排查：四种典型场景

排班模块看起来简单，实际跑起来最容易出问题的是边缘逻辑。我在本地测试时遇到过这么几种情况：

第一种，同一个医生被配了两个科室的模板，系统在周一上午生成了两条排班记录。原因是模板关联科室的校验没做完整。这个问题排查起来比较隐蔽，需要通过一个临时SQL把重叠时段的排班找出来：

SELECT s1.doctor_id, s1.schedule_date, s1.period FROM schedule s1 JOIN schedule s2 ON s1.doctor_id = s2.doctor_id AND s1.schedule_date = s2.schedule_date AND s1.period = s2.period AND s1.id < s2.id;

第二种，某医生连续出诊，管理员手工调整时把下午的排班改到了上午，但没注意他上午本来就有排班，导致冲突。这是手工编辑排班最常踩的坑，所以系统里调整排班时一定要在Controller里重新走一遍冲突校验，而不是只更新数据库记录。

第三种，号源数量和实际诊室容量不一致。比如诊室A一上午只能容纳二十个患者，但某个医生模板里填了四十个号。这类问题纯靠人眼很难发现，需要做一个“号源数超过诊室容量配置”的告警接口。

第四种，停诊处理不干净。某天医生临时停诊，管理员只改了排班状态为停诊，没有联动取消该排班下所有已预约的记录，结果患者到当天仍然收到就诊提醒。正确做法是，停诊操作必须在一个事务里修改排班状态，同时把该排班下所有状态为锁定或已确认的预约批量置为取消，并给患者推送通知。

4.2 号源超售问题与兜底方案

超售是预约系统的头号风险，平时自己拿几个账号测很难测出来，但只要用压测工具或者多个浏览器窗口快速抢号，问题就会暴露得非常明显。某个排班总号源三十个，结果同时有三十五个患者在提交预约，最后数据库里出现了三十五条预约记录。

除了前面讲的selectForUpdate行锁，我还额外加了一道兜底：在appointment插入之前做一次数据校验，判断booked_slots < total_slots，并且把预约表的唯一索引建好，即使前面的服务因为异常跳过校验，数据库层的唯一约束也能拦住重复数据。很多同学容易忽略这个“数据库兜底”的意识，实际上生产环境没有人能保证代码逻辑百分之百不遗漏，唯一索引和约束是最后一道保险。

如果项目时间充裕，还可以设计一个定时任务，每五分钟扫描一次所有状态为锁定且lock_expire_time已过期的预约，将它们改为已取消，并同步扣减schedule.booked_slots。这一步是为了处理“用户提交预约后直接关掉支付页面”的场景，没有这个任务，被锁定的号源就永远释放不了，患者体验会很差。

4.3 时间与日期处理的三类坑

排班系统的运行完全依赖日期和时间，我在开发中遇到的关于时间的问题，总结下来有三类。

第一类是Java后端与MySQL数据库的时区不一致。很多机器上MySQL时区默认是UTC，而Java使用中国时区，插入datetime字段时会出现时间偏移。解决办法是在MySQL连接串上显式指定serverTimezone=Asia/Shanghai，并在建库时把库表默认时区设置成东八区。这个问题排查起来非常恶心，因为它是一种“看起来一切正常，但时间总是差几个小时”的诡异问题，网上搜到一半以上都是时区导致的。

第二类是排班生成的跨周逻辑。假设系统从周一开始生成未来三周的排班，长度为二十一天，如果只是简单地循环scheduleDate.plusDays(i)，那么本周的周一和下周的周一都会被计划覆盖到。但有些排班模板的生效范围是有起止日期的，比如某医生的模板只在他入职后的时间生效。所以模板上一定要加上effective_start和effective_end字段，生成排班时用这两个字段过滤。

第三类是前后端日期格式的边界值。前端传一个2025-06-10过来，后端解析时用LocalDate.parse没问题，但如果前端传的是2025-06-10 00:00:00这样的字符串，直接解析到LocalDate就会抛异常。比较好的做法是统一在前后端约定日期格式，后端接收参数时用@DateTimeFormat(pattern = "yyyy-MM-dd")做控制，并且对非法格式返回友好的错误提示。

5. 毕设项目打磨与答辩经验

5.1 演示Demo脚本怎么设计才出彩

做完项目，下一步就是答辩演示。很多同学的演示思路是“依次打开每个页面，说这是管理员的增删改查功能，这是医生的排班功能，这是患者的预约功能”，听起来非常流水账。建议把演示设计成一条业务故事线，让操作逻辑跟着故事走。

我常用的演示脚本是这样：先用管理员身份登录，现场新建一个科室，再录入一个医生；然后给医生配置一个“每周一三五上午出诊”的排班模板；接着手动触发未来两周的排班生成，可以看到系统自动创建了六条排班记录（因为模板是三天，生成两周排除周末后共六个上午）；再切换患者账号，到科室列表里搜索这位医生，选择上午时段，提交预约；回到管理员页面，看到该排班的已预约数从零变成一；再试着让另一个患者抢同一个排班的号，或者让同一个患者重复预约，向评委展示系统的冲突拦截提示。

这套演示流程覆盖了从基础数据维护到排班生成再到预约闭环的完整链路，每到一处都能顺势讲出对应的数据库字段和代码逻辑，等于提前设计好了答辩节奏。

另外要备一套“异常流程”演示：比如医生临时停诊，先说明规则是“停诊要联动取消所有未就诊预约”，然后实际操作一遍，让评委看到一个预约状态从“已确认”变成“已取消”，排班状态变为“停诊”。这样的细节比堆页面更能体现工程意识。

5.2 源码交付与文档整理思路

源码交付这件事，我见得太多了。很多同学最后交付的时候给一个压缩包，里面代码和图数据库SQL混在一起，没有任何README，连启动方式都要自己猜。这种做法到了导师验收或答辩时非常吃亏，代码再好，对方看不懂也没用。

我建议源码包里至少要有这几样东西：

• 一份详细的README.md，写清楚项目简介、技术栈、启动步骤、默认账号、测试数据说明。启动步骤一定要写具体，包括JDK版本、MySQL初始化命令、前端依赖安装命令、前后端启动顺序。
• 一份database目录，内含完整的建库建表SQL，以及必要的初始数据（比如科室数据、演示账号、部分排班模板数据）。
• 一份docs目录，放系统设计文档，重点是ER图、核心接口说明、状态机定义。这张状态机图很关键，答辩时画出来，老师一眼就知道你对业务理解透彻。
• 源码里的关键业务类要有简短注释，不需要每行都注，但排班生成、预约事务、定时释放这几个核心方法必须有注释。

我个人的习惯是，写代码的时候就把接口注释写好，用Swagger生成接口文档。这样到写文档的时候，只需要把Swagger导出的内容整理一下就能直接复用，能省很多时间。

再提醒一句：不要在源码包里放任何真实的账号密码、服务器地址或者个人信息。演示数据就写清楚是演示数据，这是安全习惯，也是基本职业素养。

这套项目我前后整理过好几遍，在实际操作中的体会是：排班与预约系统的难点从来不在页面多花哨，而在于把规则约束和状态流转设计得滴水不漏。你花在数据库唯一索引、超时释放、冲突检测上的时间，最终都会在答辩和面试时换成实实在在的加分项。如果后续还想扩展，可以往三个方向走：一是增加号源放号策略（比如提前N天放号）、二是增加诊间加号流程、三是做简单的医生工作量统计报表，每一条都够写成新的硕士课题了。用这套基础打底，往上叠加业务只会越来越顺。