会员制医疗预约系统设计：从排班防冲突到预约防超卖的工程实践

毕业设计做医疗预约系统，很多人第一反应就是“又是个增删改查”，但真正动手之后才发现，这里面的坑比想象中要多得多。会员制、预约、排班、支付这几个模块一旦搅在一起，业务逻辑的复杂度会直线上升。我当初做这个项目的时候，踩了不少雷，也总结了不少经验。今天就把整个【会员制医疗预约服务管理信息系统】从需求拆解到核心代码实现，再到避坑指南，完整地梳理一遍。

这篇内容适合正在准备毕业设计的技术类学生，也适合刚入行想做管理系统练手的开发者。无论你是用 Java 还是别的技术栈，核心的设计思路都是通用的。我会把当初设计时踩过的坑，以及后来总结出的更合理的做法一并写出来。尤其会员等级、医生排班、时段抢占这三块，是这类系统的灵魂，值得你多花点心思。

1. 整体设计思路与需求拆解

1.1 核心需求解析：这不是普通的“挂号系统”

先说清楚一个容易被忽略的点：会员制这三个字决定了系统绝不只是简单的预约和挂号。

普通挂号系统核心是“选医生、选时间、付款、取号”，但会员制医疗预约服务管理信息系统多了一层用户运营的逻辑。也就是说，你需要把用户分为普通用户、银卡会员、金卡会员等不同等级，不同等级享有不同的权益，比如优先预约权、折扣、积分翻倍、专属客服等。

所以我对核心需求的拆解是这样的：

• 用户侧：注册、登录、完善健康档案、浏览医生排班、在线预约、取消预约、支付、会员开通与续费、查看历史记录。
• 医生侧：查看个人排班表、设置可预约时段、处理预约请求（确认/取消）、填写简单诊断记录。
• 管理端：科室管理、医生管理、会员等级配置、预约规则配置（如提前天数、取消时限）、数据统计、系统公告。
• 核心约束：验证不同等级会员是否真的有不同体验，预约时段不能冲突，医生排班不能重复，同一个时间段不能被两个人同时约走。

这种设计思路，本质上就是把“医疗流程”和“会员运营逻辑”做了一次融合。很多同学做这类题目容易只盯着医疗流程本身，结果做出来就是一个带界面的表格，毫无业务特色。毕业设计要想拿高分，关键不在于功能多华丽，而在于你是否能把“会员权益”和“预约流程”环环相扣。

1.2 技术架构选型：保守但别落伍

这类管理系统，稳妥的技术方案就是 Spring Boot + Vue 前后端分离，数据库用 MySQL。如果你对容器化有了解，可以加 Docker 部署，但这属于加分项，不是必须项。

我当初用的是：

• 后端：Spring Boot 2.7.x + MyBatis-Plus + Spring Security + JWT
• 前端：Vue 3 + Element Plus + Pinia + Axios
• 数据库：MySQL 8.0
• 缓存：Spring Boot 自带的 Caffeine 本地缓存（不需要 Redis 也能撑住中小流量）

这里说下选型的思路。Spring Boot 是市场主流，资料多，遇到问题容易查；MyBatis-Plus 能极大减少单表 CRUD 代码量，适合毕设这种开发周期有限的项目；JWT 做无状态登录非常契合前后端分离。而 Vue 3 + Element Plus 的组合对于后端学生来说，上手成本相对可控，后台管理界面也好看。

不使用 Redis 而用本地缓存，原因很简单：毕设系统没有高并发压力，引入 Redis 反而要额外配置，增加部署负担。当然，如果论文里想体现高并发设计思路，可以在架构说明里提到无缝迁移到 Redis 的方案，但实现落地就以本地缓存为主。论文里写清楚“当前阶段用本地缓存，系统扩展时可平滑升级”也是一种设计上的严谨。

2. 核心模块设计：数据库与会员规则

2.1 数据库设计实战：核心表结构规范

数据库设计上，我前后重构过两次。第一次表设计太粗糙，导致后来加会员权益功能时几乎要推倒重来。这里给你一份我最终沉淀下来的核心表设计，尽量把你可能踩的坑提前抹平。

用户表user

会员等级表member_level

医生表doctor

科室表department

排班表schedule

预约记录表appointment

支付记录表payment：记录金额、支付方式、支付时间、流水号。

积分记录表points_log：积分变动明细，包含来源、变动值、创建时间。

这里重点提一下unique_key字段。我当时就是忽略了它，导致同一医生在同一时段可以被插入两条排班记录。加了唯一索引之后，数据库层面就能挡住重复数据，比在代码里用 if 判断可靠得多。

2.2 会员等级规则的设计原则

会员等级这部分，我一开始想得很简单：数据库加个member_type字段就完事了。后来发现完全不够，因为会员算价逻辑涉及到原价、折扣价、积分返利三条线，分开处理才够清晰。

设计原则主要有四条：

1. 用配置文件或数据库管理等级参数，不要写死在代码里。比如折扣率、积分倍率、开通价格，这些值后续一定会调整，写死就是给自己挖坑。
2. 会员到期时间要单独存，不要只存一个等级。用户续费的时候要基于当前到期时间叠加，而不是简单覆盖为当前时间加一个月。
3. 支付金额、原始金额、优惠金额三列分开存。你可能觉得多此一举，但月底对账、论文里写数据分析、甚至后期做报表，全靠这三个字段拆开才有数据。
4. 预约创建时要锁定会员当时的等级和价格，而不是每次展示时动态算。否则用户约完后等级变了，订单金额对不上账。

嗯，这四条里面，第三条是最容易被人忽视的。单单一个订单金额字段，写论文时做“优惠分析”会发现数据完全不够用。

3. 核心功能实现：预约、排班与会员权益闭环

3.1 排班模块：唯一约束与时段防冲突

排班是整个系统的地基。排班没做好，预约一定会乱。

排班的本质就是把医生的可出诊时间切成多个时段，每个时段可以约 N 个人。如果你的系统是“每个时段只能约一个人”，那就把它设计成total_slots=1的特例，而不是完全不做号源数量控制。

数据库层加唯一索引：

ALTER TABLE schedule ADD UNIQUE KEY uk_doctor_time (doctor_id, work_date, start_time, end_time);

这行代码的意图很简单：同一个医生在同一天同一个时间段，物理上就不能存在两条排班记录。现实中很多前端重复提交的 bug，在后端“数据库唯一索引”面前都可以自动免疫。

排班生成的接口简单示例如下：

public Result addSchedule(ScheduleDTO dto) { // 1. 检查医生是否存在且状态正常 Doctor doctor = doctorMapper.selectById(dto.getDoctorId()); if (doctor == null || doctor.getStatus() != 1) { return Result.error("医生不存在或未开放预约"); } // 2. 检查日期是否合法（不能排过去的时间） if (dto.getWorkDate().isBefore(LocalDate.now())) { return Result.error("不能排过去的日期"); } // 3. 创建排班记录，初始剩余号源=总号源 Schedule schedule = new Schedule(); schedule.setDoctorId(dto.getDoctorId()); schedule.setWorkDate(dto.getWorkDate()); schedule.setStartTime(dto.getStartTime()); schedule.setEndTime(dto.getEndTime()); schedule.setTotalSlots(dto.getTotalSlots()); schedule.setRemainSlots(dto.getTotalSlots()); // 4. 捕获数据库唯一索引冲突 try { scheduleMapper.insert(schedule); } catch (DuplicateKeyException e) { return Result.error("该时段已存在排班，请勿重复添加"); } return Result.success(schedule); }

注意第 4 步。很多人在代码里先查询再判断“是否存在”，但查询和插入之间存在时间差。即便你的并发量不高，也建议养成“直接插入，靠数据库约束兜底”的习惯，这是性价比最高的防重方案。

3.2 预约模块：事务、锁与号源扣减

预约是整个系统最核心的业务，也是并发问题最集中的地方。

预约流程本身不复杂：用户选时段 → 计算应付金额 → 创建订单 → 扣减号源 → 模拟支付 → 生成预约单。难点在于：如果两个用户同时抢最后一个号源，怎么做才能不超卖？

给你三种方案，按可靠性从低到高排列：

方案一：先查询再更新（不推荐）

Schedule schedule = scheduleMapper.selectById(scheduleId); if (schedule.getRemainSlots() > 0) { schedule.setRemainSlots(schedule.getRemainSlots() - 1); scheduleMapper.updateById(schedule); // 创建预约单 }

这段代码在单用户场景下没问题，但在并发场景下，两个事务都读到了remainSlots=1，就会同时通过判断，同时扣减，最终变成 -1。这就是超卖。

方案二：乐观锁（推荐）

int update = scheduleMapper.updateRemainSlots(scheduleId); if (update == 0) { return Result.error("号源已满，预约失败"); }

配合 SQL：

UPDATE schedule SET remain_slots = remain_slots - 1 WHERE id = #{scheduleId} AND remain_slots > 0;

这条 SQL 的意思是：要更新行记录，必须满足remain_slots > 0。如果剩余号源不够，更新影响的行数就是 0，代码就能马上判断出来。

方案三：悲观锁（性能换取绝对安全）

SELECT * FROM schedule WHERE id = #{scheduleId} FOR UPDATE;

加FOR UPDATE之后，其他事务必须等当前事务提交才能操作这一行。这只是理论方案之一，毕设阶段用方案二就够了，既不需要额外引入中间件，又能体现你的并发意识。

预约核心代码（基于方案二）：

@Transactional(rollbackFor = Exception.class) public Result createAppointment(CreateAppointmentDTO dto) { Long userId = dto.getUserId(); Long scheduleId = dto.getScheduleId(); // 1. 幂等：同一个用户同一排班不能有状态为待确认或已确认的订单 int existCount = appointmentMapper.checkExist(userId, scheduleId); if (existCount > 0) { return Result.error("您已在同一时段预约过，请勿重复预约"); } // 2. 查询排班信息 Schedule schedule = scheduleMapper.selectById(scheduleId); if (schedule == null) { return Result.error("排班不存在"); } if (schedule.getWorkDate().isBefore(LocalDate.now())) { return Result.error("该排班已过期"); } // 3. 原子扣减号源 int rows = scheduleMapper.deductRemainSlots(scheduleId); if (rows == 0) { return Result.error("该时段号源已被约满"); } // 4. 计算价格（会员价格） User user = userMapper.selectById(userId); PriceCalculator priceCalculator = PriceCalculator.valueOf(user.getMemberLevel()); // 原价 BigDecimal originalAmount = schedule.getPrice(); // 实际支付金额 BigDecimal realAmount = priceCalculator.calculate(originalAmount); // 5. 创建预约单 Appointment appointment = new Appointment(); appointment.setAppointmentNo(generateAppointmentNo()); appointment.setUserId(userId); appointment.setScheduleId(scheduleId); appointment.setOriginalAmount(originalAmount); appointment.setRealAmount(realAmount); appointment.setStatus(1); // 待确认 appointment.setPayStatus(0); // 未支付 appointmentMapper.insert(appointment); return Result.success(appointment); }

要理解一下事务在这里的作用。我手动执行了“扣减号源”和“创建预约单”两步操作，如果中间报错，事务回滚可以把已经扣掉的号源恢复。这是保证数据一致性的关键。

PriceCalculator是我抽出来的一个简单策略类，意图是避免在业务代码里写一大堆 if-else 判断会员等级。以后新增会员等级，只需要扩展这个类，不用动核心业务逻辑。

3.3 会员权益闭环：开通、续费与积分

会员权益要实现“闭环”，不能只做开通。一个完整的会员体系至少要能回答三个问题：

1. 用户怎么变成会员？
2. 会员在使用权益时，系统能不能准确的识别？
3. 会员期满后，相关信息——比如状态降级、积分结算——怎么处理？

开通会员的接口，我的做法是在事务里先创建支付订单，支付成功后把user.member_level修改为目标等级，同时把member_expire_time设置为“当前时间和原到期时间中较晚的那个再加一个月”。

这里有个容易想错的点：有同学把过期时间直接写成new Date()+ 30天。如果用户原本还剩 20 天会员，这样一覆盖就直接损失了 20 天。正确做法是在原member_expire_time基础上叠加，用if (expireTime.isAfter(now)) newExpire = expireTime.plusMonths(1); else newExpire = now.plusMonths(1);。

积分方面，设计一个points_log表做流水记录，预约完成后按原价的积分倍率发放积分。积分可以用于抵扣订单金额（比如 100 积分抵 1 元），也可以单纯作为等级成长值。毕设阶段建议做到“积分抵钱”和“积分流水查询”就足够了，没必要把所有营销玩法都做进去。

4. 技术要点：缓存、接口安全与数据一致性

4.1 本地缓存如何缓存医生排班信息

在用户端首页，通常要展示“热门科室”“医生列表”“未来一周排班”，这些数据变化频率不高，如果每次都查数据库，性能上是浪费。

我的做法是：项目里引入 Caffeine，配置一个两分钟过期的本地缓存。管理员或医生更新排班时，主动调用一个“清除缓存”的接口。这样既保证数据不会长久失真，又避免每次都穿透到数据库。

@Component public class CacheConfig { private final Cache<String, List<ScheduleVO>> scheduleCache = Caffeine.newBuilder() .expireAfterWrite(Duration.ofMinutes(2)) .maximumSize(10_000) .build(); public List<ScheduleVO> getScheduleList(String key) { return scheduleCache.get(key, k -> scheduleService.queryListFromDb()); } }

缓存键可以设计成schedule:doctor:{doctorId}或者schedule:date:{date}。原则上，页面变化频率低的信息适合缓存，和用户强相关、实时性强的数据（比如用户自己的预约单）就不要走缓存了。

4.2 接口安全：JWT、参数校验与防重复提交

前后端分离的系统，后端接口必须做权限控制。我用的方案是 Spring Security + JWT。给用户接口和管理员接口区分不同的路径访问控制，关键点在于 JWT 拦截器里要校验 token 是否过期、用户状态是否正常。

@RequestBody参数校验不能只靠前端。后端必须加上@Validated注解配合@NotNull、@Pattern这些注解来拦截非法参数。比如手机号格式、预约日期格式，在 DTO 层就要校验好。

除了这些常规校验，防重复提交也是一定要做的。最简单的做法是前端在点击“提交预约”后把按钮变成 loading 状态并禁用。但真正的后端防线，可以参考我上文的处理方式：给同一个用户同一排班加唯一约束。用户实际操作中比较容易出现的场景是：用户网不好，点了一下没反应，又点了一下，结果生成了两条预约记录。加了幂等约束后，第二条预约会被直接拒绝。

另外再分享一个通用技巧：约定一个@RepeatSubmit注解，配合拦截器把用户 ID + 接口路径 + 请求参数摘要存进缓存，并在几秒内判断重复，效果很好。不过毕设阶段，数据库层面的幂等约束已经足够用了。

4.3 数据一致性：事务边界怎么划

最需要划清事务边界的是“预约流程”，其次是“支付回调”。我在设计预约流程事务的时候，把“扣号源”和“创建预约单”放在一个事务里。支付系统是模拟的，前端的模拟支付回调到后端之后，再开启一个事务去更新支付状态和预约单状态。

做过一段时间的开发后你就会明白，真实业务里很多问题都出在事务边界上。事务太小，中间环节一旦报错会留下脏数据；事务太大，长事务会锁住数据库资源，影响其他请求。因此我的经验是：在预约流程这种短平快的操作里，一个事务包到底；在涉及第三方的场景里（比如接真实支付系统），事务只负责本地数据更新，网络请求绝不能放在事务内部。

5. 常见问题与排查技巧实录

5.1 预约超卖问题复盘

这个问题的表象是：明明同一个时段只剩一个号源，却有两个用户都预约成功了。

排查步骤和方法如下：

1. 先看数据库里是不是真的存在两条预约记录（状态都是已确认）。
2. 检查预约接口的扣减号源 SQL 是不是“先查再减”，如果是，把它替换成UPDATE schedule SET remain_slots = remain_slots - 1 WHERE remain_slots > 0。
3. 考虑并发测试。可以用 Jmeter 或者写一个简单的多线程并发脚本，模拟 20 个用户同时请求同一个排班 ID，观察是否有剩余号源变成负数。
4. 检查/schedule/deduct接口是不是没有加事务，导致更新成功但预约单创建失败，最终数据不一致。

这个问题排查下来，绝大部分原因是同一个：业务校验和订单创建之间没有做原子性控制。

5.2 Redis 未引入时的缓存穿透解决思路

毕设阶段不用 Redis，不代表完全没有缓存问题。

如果你用了本地缓存，关注两个点：第一是缓存击穿，即缓存失效瞬间大量请求直接打到数据库；第二是缓存与数据库不一致，即管理员改了排班，用户端还在显示旧数据。

解决思路不算难。击穿可以用“定时刷新缓存”或“逻辑过期”来处理，比如后台改了数据主动刷新缓存。不一致则是上述主动清缓存的方式，后台每次修改排班后调用“清缓存”接口即可。理解这个思路的核心比具体用什么中间件更重要。

5.3 会员等级生效延迟与过期处理

业务场景是：用户刚开通银卡会员，马上预约，但是系统还按普通用户的价格计算。原因是前端把用户信息存进了localStorage，但开通会员后没有重新获取用户信息，导致本地还持有旧的等级数据。

处理方案是：用户开通或续费成功后，前端调用/user/info重新拉取用户信息，并更新到本地存储。后端接口里，预约时的会员等级以数据库最新数据为准，尽量不要用前端传来的字段。

对于过期用户，需要一个定时任务来做“每日检查”。核心逻辑是：查出所有member_expire_time早于今天的用户，把等级降为普通用户，并且按规则结算到期积分。这个定时任务建议在论文里写成“系统自动运维模块”，实际只负责几行 SQL 更新，但整体规范性会好很多。

6. 项目展示与答辩准备建议

6.1 核心功能演示清单

做演示的时候最好别临场发挥，提前想好流程，防止做到一半出问题。我建议按下面这个顺序演示：

1. 用户注册登录，完善健康档案。
2. 用户开通会员（模拟支付成功后查看等级变化）。
3. 按科室浏览医生列表，查看排班。
4. 选择一个时段预约，查看订单金额变为折扣价。
5. 模拟支付，查看预约记录状态变化。
6. 取消预约，查看号源是否回补。
7. 管理员登录，新增医生、排班、配置会员等级折扣。
8. 查看预约统计报表数据。

这个顺序有一个好处：你的演示逻辑实际上是一条完整的业务闭环。从用户注册到会员开通，从预约到支付，再到管理员后台操作，每一步都跟下一步有因果关系。

6.2 论文中可以重点展开的创新点

毕设的论文部分，一定不要只写功能说明，要体现“你是怎么思考的”。我把我在论文里重点展开的点列在下面：

• 会员等级策略模式的设计：如何把多种会员权益的差异封装在策略类里，避免业务代码膨胀。
• 预约并发控制策略：乐观锁 + 数据库唯一约束如何保证号源不超卖。
• 事务边界的划分：哪些操作必须同一事务，哪些不能放在事务里。
• 数据统计报表：设计思路与 SQL 聚合实现，比如近 30 天预约量趋势折线图。
• 缓存设计与一致性保证：本地缓存如何用于读多写少的场景。

这些点对应的不是冷冰冰的功能，而是你在项目里真实做过的、有取舍的技术方案。答辩时把这些讲清楚，指引思路呈现到位，比罗列功能清单更能支撑起整个项目的深度。

最后说说我个人的实操体会

整个项目做下来，我最大的体会还不是代码怎么写，而是“需求看清楚再动手”这句话有多重要。会员制医疗预约系统牵扯到的不是一张表的 CRUD，而是会员权益、排班唯一性、预约超卖、支付回调这一串咬合很紧的环节。如果刚拿到题目就开始写代码，后期大概率会重构好几次。

再分享一个小技巧：预约号的生成，可以用yyyyMMddHHmmss+ 用户ID后四位 + 随机数组合。有唯一性、可读性也好，日志排查问题的时候一眼就能看出是哪天的单子。我当时就是因为直接用了自增 ID 当预约号，后期导出数据、排查问题都非常痛苦。

这个项目往深了做，还可以扩展医生评价、慢病随访、家庭医生签约服务等模块。如果论文需要做扩展性设计说明，这些都是很好的落笔点。但核心的预约、排班、会员、支付这四条业务链路，一定要走得通、演示得顺。做完这套东西，你对 Spring Boot 的事务控制、并发处理、权限体系、缓存设计等知识点都会有真切的体感认知，这比只看书要值太多了。