陆冠均(opllx)排课系统是培训机构绕不开的一个坎。我去年帮一家教练培训机构做内部管理系统，排课模块前后改了四版才算稳定下来，踩过的坑包括时间冲突漏判、预约超卖、教练时间被重复占用，每一类问题都折腾了好几天。这篇文章把排课系统源码开发这一路的思路完整捋一遍，从需求拆解到数据模型，从冲突检测算法到接口落地，再到并发和性能的常见坑位。照着这套方案，有Java基础的同学完全可以自己在本地把一版可用的排课系统跑起来，既能当项目经验写进简历，也能直接拿去做毕业设计或者培训机构的内部工具。
1. 排课系统需求拆解与整体设计思路
1.1 业务场景分析：为什么培训机构需要一套排课系统
表面上看，排课系统就是"把教练的空闲时间和学员的上课需求做个匹配"，但真正落地的时候你会发现，这里面的业务规则多到让人头皮发麻。以教练培训机构为例，一个机构通常有几十名教练、几百名学员、多门课程，每门课程时长不同、难度不同，教练擅长领域也不同。学员约课要按自己的空闲时间来，教练排课要考虑体力和通勤，机构运营还要统计每节课的上座率、教练的课时费。
没系统的时候，前台用Excel排课，一人一个sheet，排完导出发群里。听起来也能跑，但只要出现"教练临时请假""学员调课"这些高频操作，Excel的劣势就暴露无遗了。改一处时间要手动检查冲突，改多了就容易漏，实际运营中经常出现两位学员被约到同一个教练的同一时段，或者教练连上八个小时课这种反人类排班。
所以排课系统的核心价值不是"把课排出来"，而是"在排课和变动的过程中，始终维护数据的正确性"。系统需要保证同一时间同一教练在不同课程之间不冲突、学员同一时间不会被约到两节课、超过容量的课不能继续被预约。这种正确性不能靠人在录入时小心，必须靠系统在数据层和应用层做双重约束。
1.2 技术选型考量：用Java生态做排课系统的底气
技术方案上，主流选择没有悬念：Java + Spring Boot + MyBatis-Plus + MySQL。这套组合在中小型管理系统中几乎是事实标准，Spring Boot 负责接口层和依赖管理，MyBatis-Plus 提供基本的CRUD和分页能力，MySQL负责数据持久化，Redis 按需引入，用来做热点缓存和分布式锁。
为什么推荐这套组合而不是其他语言或者更重的框架？原因有三个：
第一，团队人才供给充足。Java开发的招聘池子最大，培训机构内部甚至学员自己也都会Java，后续维护不会因为某个人的离开而陷入困境。
第二，生态成熟，社区资料丰富。排课系统涉及的日历处理、状态流转、时间区间判断等问题，在Java生态里都有大量现成解决方案和踩坑记录，出问题搜得到答案，这对个人项目或者小团队来说太重要了。
第三，部署运维不挑环境。Spring Boot 打包成jar包，Java 8以上环境就能跑，不管是部署到云服务器还是普通的Windows机器都没有压力，后期迁移成本低。
有人可能会问，为什么不用Python或者Go？也可以，但从招聘、维护、培训机构这种特定业务场景来说，Java的综合成本最低。这不是说Java比别的语言好，而是"在你需要长期维护的项目里，选团队和社区最熟悉的技术栈"才是正确的选型逻辑。
1.3 模块划分与功能边界
一个完整的排课系统，按功能域拆可以分成五大模块：
- 基础信息模块：教练信息、学员信息、课程信息的管理，这是排课的基础数据，教练要有擅长课程、学员要有等级，课程要有默认时长。
- 排课管理模块：核心模块，负责课表维护，包括创建课时计划、调整上课时间、停课、取消课程。这里的核心操作是"在某一天给教练排出一节课"。
- 预约管理模块：学员端的行为入口，包括查询可预约课程、发起预约、取消预约、确认到场、标记爽约。
- 课时记录模块：记录每一节实际发生的课程数据，关联教练、学员、课程、时间、费用，为课时费结算和统计报表提供数据来源。
- 报表统计模块：教练课时统计、课程预约率、学员出勤率、取消率，这些数据是机构运营决策的基础，但同一个系统里可以放在后台看板，不必单独开发。
模块划分的原则是"高内聚低耦合"，排课管理不直接操作学员数据，预约管理也不直接改教练表。模块之间通过服务层调用，避免在Controller层交叉依赖。实际编码时，我倾向于按包结构划清边界：controller、service、mapper、entity 各司其职，业务逻辑全部收敛在service层，这样后面加功能或者排查问题时，定位代码的效率会高很多。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 核心数据模型设计：排课系统的地基
2.1 教练、学员、课程三大基本实体的表结构
数据库设计是排课系统中最关键的部分。表结构不好，后面的代码全得跟着返工，所以在建表之前一定要想清楚每一张表要回答什么业务问题。
教练表保存教练的基础信息，核心字段包括姓名、手机号、擅长课程、等级、状态。注意这里的"擅长课程"字段，如果教练可能擅长多门课程，就不要用单个字段存字符串，要拆一张关联表。但为了给读者保留一个简单的初始版本，我们先在一对一的场景下做。
学员表新增了"体验次数"这样的业务字段，这是为了方便做"首次体验课免费"之类的营销活动。排课系统不止是排时间，很多时候还要承接机构的运营规则，这一点在建模的时候就要考虑到。
课程表比较简单，但有一个字段值得注意：duration_minutes。排课的时候需要根据课程的默认时长自动生成上下课时间，比如"科目二"默认50分钟，"科目三"默认90分钟，课程结束后有课间休息，这个字段是排课的基准。
以下是建表SQL的核心部分：
sql复制CREATE TABLE coach (
id BIGINT PRIMARY KEY AUTO_INCREMENT COMMENT '主键',
name VARCHAR(64) NOT NULL COMMENT '教练姓名',
phone VARCHAR(20) NOT NULL COMMENT '手机号',
skill_level VARCHAR(32) COMMENT '教练等级',
status TINYINT NOT NULL DEFAULT 1 COMMENT '1在职 0离职',
created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
UNIQUE KEY uk_phone (phone)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='教练表';
CREATE TABLE student (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
name VARCHAR(64) NOT NULL COMMENT '学员姓名',
phone VARCHAR(20) NOT NULL COMMENT '手机号',
level VARCHAR(32) COMMENT '学员等级',
trial_count INT NOT NULL DEFAULT 0 COMMENT '体验课次数',
status TINYINT NOT NULL DEFAULT 1 COMMENT '1正常 0冻结',
created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
UNIQUE KEY uk_phone (phone)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='学员表';
CREATE TABLE course (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
name VARCHAR(64) NOT NULL COMMENT '课程名称',
course_type VARCHAR(32) COMMENT '课程类型',
duration_minutes INT NOT NULL COMMENT '课程时长（分钟）',
price DECIMAL(10,2) NOT NULL DEFAULT 0 COMMENT '课程单价',
status TINYINT NOT NULL DEFAULT 1 COMMENT '1上架 0下架',
created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='课程表';
注意这里主键用了BIGINT自增，而不是UUID。对于排课系统这种中小体量的业务，自增主键的索引效率和存储开销都比UUID好。如果未来有分库分表的需求，再换雪花算法也来得及，现在用自增是性价比最高的方案。
2.2 排课核心表：课时计划与预约记录
排课系统的核心是两张业务表：课时计划表（lesson_plan）和预约记录表（booking）。
课时计划表记录一条"课程安排"，也就是某个教练在某个时间段教授某一门课程。关键字段有教练ID、课程ID、上课日期、开始时间、结束时间、最大可预约人数、已预约人数、状态。这里有一个容易忽略的设计点：max_students字段。排课系统的业务场景通常是"小班课"，也就是一个教练同时带几个学员，所以一节课可以容纳多个学员，需要一个容量字段来控制预约人数上限。
上课日期、开始时间、结束时间这三列是排课的核心，也是后面做冲突检测的主要字段。为了让查询更高效，可以加一个联合索引，把教练ID和上课日期放在前面，这样可以快速查出一个教练某一天的所有课程安排。
预约记录表记录学员和课时之间的关联，一张预约记录对应一名学员对一节课的预约，字段包括课时ID、学员ID、预约时间、状态。这里必须加一个唯一约束：uk_lesson_student(lesson_id, student_id)，它的作用是防止同一个学员重复预约同一节课。
sql复制CREATE TABLE lesson_plan (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
coach_id BIGINT NOT NULL COMMENT '教练ID',
course_id BIGINT NOT NULL COMMENT '课程ID',
lesson_date DATE NOT NULL COMMENT '上课日期',
start_time TIME NOT NULL COMMENT '开始时间',
end_time TIME NOT NULL COMMENT '结束时间',
max_students INT NOT NULL DEFAULT 1 COMMENT '最大预约人数',
booked_count INT NOT NULL DEFAULT 0 COMMENT '已预约人数',
status TINYINT NOT NULL DEFAULT 0 COMMENT '0待开始 1进行中 2已完成 3已取消',
remark VARCHAR(255) COMMENT '备注',
created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
KEY idx_coach_date (coach_id, lesson_date),
KEY idx_course_date (course_id, lesson_date)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='课时计划表';
CREATE TABLE booking (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
lesson_id BIGINT NOT NULL COMMENT '课时ID',
student_id BIGINT NOT NULL COMMENT '学员ID',
status TINYINT NOT NULL DEFAULT 0 COMMENT '0已预约 1已取消 2已完成 3爽约',
booking_time DATETIME NOT NULL COMMENT '预约时间',
created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
UNIQUE KEY uk_lesson_student (lesson_id, student_id),
KEY idx_student (student_id, status)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='预约记录表';
为什么预约记录只保存"预约状态"而不是"到场状态"？因为到场状态其实是"课时完成状态"的一部分，需要在课时结束以后统一更新。如果把到场状态放在预约记录里，那每一条预约记录都要有一个状态，数据冗余不说，状态管理还会变得复杂。合理的设计是预约状态只关心"预约—取消"这个生命周期，到场与否则在课时完成时统一处理。
2.3 数据库索引与唯一约束的设计技巧
索引设计直接决定了排课系统在数据量上来之后还跑不跑得动。索引不是越多越好，而是要给"高频查询路径"建索引。
排课系统的查询路径主要有四条：
- 查某教练某一天的课程安排：走
idx_coach_date(coach_id, lesson_date)。 - 查某教练某一周的课程安排：同样走这个联合索引，时间范围扩大。
- 查某课程某一天的排课情况：走
idx_course_date(course_id, lesson_date)。 - 查某学员的预约记录：走
idx_student(student_id, status)。
唯一约束是数据正确性的最后一道防线。我特别强调预约记录表里的 uk_lesson_student 约束，这个约束保证了即使应用层代码出了bug，数据库层面也不会让同一个学员在同一节课里出现两条预约记录。这不是冗余设计，这是"防御性编程"在数据库层面的体现。
但要注意一点：唯一约束能防重复，不能防超卖。也就是说，uk_lesson_student 可以防止同一个学员预约两次同一节课，但两个不同的学员同时预约同一节课时，数据库层面不会因为 booked_count >= max_students 而拒绝插入。这个容量控制必须在应用层加锁实现，后面在并发章节我会细说。
3. 排课核心算法：时间冲突检测与时段分配
3.1 冲突检测的两种思路：数据库约束 vs 应用层判断
排课系统最核心的算法需求是时间冲突检测，也就是判断"同一教练在同一时间是否有两节课"。这里有两种实现思路：数据库约束和应用层判断。
数据库约束的做法是创建一个"教练时间占用表"，把教练的一天按固定粒度（比如30分钟）拆成多个时间段，每个时间段一条记录，然后对 (coach_id, time_slot) 加唯一索引。排课的时候先写入时间占用表，写入成功就说明该时段空闲。理论上这样做可以实现数据库级别的冲突检测。但实际落地很不优雅：一天的粒度是30分钟的话，一个教练一天要生成几十条记录，一周就是几百条，两三个教练的数据量就开始膨胀。而且如果课程时长不是30分钟的整数倍（比如50分钟的课程），时间段拆分就很麻烦，边界情况多到让人崩溃。
应用层判断的做法是：排课前先查询该教练在相关时间段内的已有课时计划，然后在内存中进行区间重叠判断。区间重叠判断本身很简单，时间复杂度O(1)就能判断两个时间段是否重叠。但问题在于应用层操作之间有间隙，并发场景下会出现"超卖"问题。解决并发问题的思路是在事务里用 SELECT ... FOR UPDATE 对教练当天的课时记录加悲观锁，或者引入第三方分布式锁。相比数据库的时间表方案，应用层+锁的实现复杂度更低、可扩展性更强，是目前最常用的方案。
综合来看，我强烈建议用"应用层区间判断 + 数据库唯一约束兜底"的组合方案。区间判断负责业务规则，唯一约束负责最后防线，这样既保证了功能的完整性，又控制了实现复杂度。
3.2 时段生成与优先级分配策略
排课系统除了被动录入排课，还应该支持"自动排课"的简单能力。比如课程顾问想给新人学员安排自动连续十天的训练计划，或者运营想"为教练生成下一周的默认课表"，这些场景需要系统能够自动生成可选时段。
时段生成的核心逻辑是：给定教练的工作时间范围（比如上午9点到下午6点），给定课程时长（比如50分钟），按固定步长生成所有可选的开始时间。步长通常是课程时长加上课间休息时间，课间休息建议设置10到15分钟，让教练有间隔时间，也方便学员转场。
生成算法非常简单，用一条Java循环就能完成：
java复制public List<LocalTime> generateCandidateSlots(LocalTime workStart, LocalTime workEnd, int courseMinutes, int gapMinutes) {
List<LocalTime> slots = new ArrayList<>();
LocalTime current = workStart;
while (current.plusMinutes(courseMinutes).isBefore(workEnd) || current.plusMinutes(courseMinutes).equals(workEnd)) {
slots.add(current);
current = current.plusMinutes(courseMinutes + gapMinutes);
}
return slots;
}
生成的候选时段并不能全部展示给用户，还要做两轮过滤。第一轮过滤掉教练已有课程的时间区间，第二轮过滤掉学员已约课的时间区间。只有当教练和学员都空闲的时段，才是真正可预约的时段。
这里有一个容易被忽略的优先级问题：如果某位金牌教练的空闲时段很少，而请求的学员是VIP学员，系统是否应该优先把时段分配给VIP？实际项目中，我建议在初始版本里不做复杂的时间片竞价和优先级调度，而是采用"先到先得"策略，同时在排序上把热门教练的靠前时段标记为"紧张"状态。等系统跑起来收集到真实数据之后，再考虑引入更细的优先级策略。过早做复杂策略只会增加项目风险，不会带来直接收益。
3.3 核心代码实现：Java中的区间重叠判断
区间重叠判断是整个排课系统最核心的算法，值得拆开讲清楚。两个时间段 [start1, end1) 和 [start2, end2) 重叠的条件是：
code复制start1 < end2 AND start2 < end1
这里用的是左闭右开区间，也就是说开始时间包含在内、结束时间不包含在内。这样约定有一个好处：一个课程10:00结束，另一个课程10:00开始，它们不算冲突。用生活经验来理解就是"下课时间和上课时间重合的那一刻，教练是可以切换的"。
在排课场景里，判断的逻辑是：已有课程的时间区间是 (lessonStart, lessonEnd)，新课程的时间区间是 (newStart, newEnd)，两个区间重叠就说明教练在冲突时间已经有安排了。在Java中实现如下：
java复制public boolean isTimeConflict(LocalTime lessonStart, LocalTime lessonEnd,
LocalTime newStart, LocalTime newEnd) {
return lessonStart.isBefore(newEnd) && newStart.isBefore(lessonEnd);
}
有人可能会问，直接枚举教练当天所有课再逐个判断，效率会不会有问题？其实完全不用担心。一个教练一天最多也就十几节课，遍历一次的开销微不足道。真正需要关注的是查询本身要不要把教练当天的课程全部load到内存。我建议的做法是：只查询上课日期当天、结束时间大于当前时刻的未取消课程，用一个 SELECT * FROM lesson_plan WHERE coach_id = ? AND lesson_date = ? AND status != 3 就能覆盖绝大多数场景。
4. 核心业务模块的实现细节
4.1 排课接口设计：创建课时计划的完整流程
课时计划是排课系统里最基本也最核心的写入操作，调用方提交教练ID、课程ID、上课日期和开始时间，后端要根据课程表里的课程时长和课间休息自动计算出结束时间，然后做冲突检测，最后落库。
流程设计上，我有几个建议。第一，结束时间不要交给前端传入，而是由后端根据课程表统一计算，前端只需要告诉后端课程ID和开始时间，这样避免前端手算错误或者篡改数据。第二，在事务内做冲突检测和插入，事务隔离级别用默认的即可。第三，插入之后立刻返回课时ID和完整的课时信息，方便前端刷新排课界面。
核心的Service层实现如下：
java复制@Transactional(rollbackFor = Exception.class)
public LessonPlanVO createLessonPlan(LessonPlanCreateRequest request) {
// 1. 查询课程基本信息，获取课程时长
Course course = courseMapper.selectById(request.getCourseId());
if (course == null) {
throw new BizException("课程不存在");
}
// 2. 校验教练存在且在职
Coach coach = coachMapper.selectById(request.getCoachId());
if (coach == null || coach.getStatus() != 1) {
throw new BizException("教练不存在或已离职");
}
// 3. 计算结束时间
LocalTime startTime = request.getStartTime();
LocalTime endTime = startTime.plusMinutes(course.getDurationMinutes());
if (endTime.isAfter(LocalTime.of(22, 0))) {
throw new BizException("课程结束时间不能晚于22:00");
}
// 4. 查询教练当天的已有课程，加悲观锁防止并发修改
List<LessonPlan> existingPlans = lessonPlanMapper.selectForUpdateByCoachAndDate(
request.getCoachId(), request.getLessonDate());
// 5. 逐个检查时间冲突
for (LessonPlan plan : existingPlans) {
if (isTimeConflict(plan.getStartTime(), plan.getEndTime(), startTime, endTime)) {
throw new BizException("该教练在该时间段已有课程安排");
}
}
// 6. 创建课时计划
LessonPlan plan = new LessonPlan();
plan.setCoachId(request.getCoachId());
plan.setCourseId(request.getCourseId());
plan.setLessonDate(request.getLessonDate());
plan.setStartTime(startTime);
plan.setEndTime(endTime);
plan.setMaxStudents(request.getMaxStudents() == null ? 1 : request.getMaxStudents());
plan.setBookedCount(0);
plan.setStatus(0);
lessonPlanMapper.insert(plan);
return convertToVO(plan);
}
注意第4步用了 selectForUpdateByCoachAndDate，这个SQL需要在事务里执行，并且依据 idx_coach_date 索引锁定教练当天的课时记录。在并发排课的场景下，两个请求同时操作同一位教练的同一个时段，如果没有锁，两个事务都会通过冲突检测，然后都插入成功，造成教练时间被重复占用。加了悲观锁之后，第二个事务必须等第一个事务提交或回滚才能拿到锁，此时第一条记录已经存在，冲突检测就能正确拦下来。
4.2 预约与取消预约的状态机设计
预约模块的状态管理是整个系统里最容易出错的地方，因为涉及多个状态的变更和数据的联动更新。建议在项目初期就把状态机设计好，用一张表明确状态、触发条件和目标状态，这样后面写代码的时候就按表格对应关系来，不会漏。
预约状态机的核心流转如下：
- 已预约（0）：学员成功预约，此时
lesson_plan.booked_count加1，课时状态还是待开始。 - 已取消（1）：学员主动取消，此时
lesson_plan.booked_count减1，课时状态不变。 - 已完成（2）：课时正常结束，学员到场，状态由预约完成。
- 爽约（3）：课时已经结束但学员未到场，状态由已预约变爽约，
booked_count不减，因为该名额确实被占用了。
为什么爽约时 booked_count 不减？因为这名学员确实占用了名额，运营上需要把这个数据暴露出来，让机构看到"有学员报名了但没来"的损耗。如果把爽约的名额直接释放，运营统计就会失真。
预约的核心代码同样要处理并发。学员同时请求预约同一节课，如果该节课只剩最后一个名额，两个请求都进入了预约逻辑，都发现 booked_count < max_students，然后同时执行插入，就会造成超卖。解决思路是更新 booked_count 时使用乐观锁，SQL语句里带上 booked_count = ? 的版本条件：
java复制@Transactional(rollbackFor = Exception.class)
public BookingVO bookLesson(Long lessonId, Long studentId) {
// 1. 查询课时计划
LessonPlan lesson = lessonPlanMapper.selectById(lessonId);
if (lesson == null || lesson.getStatus() != 0) {
throw new BizException("课时不存在或已不可预约");
}
// 2. 检查是否已经预约过
int count = bookingMapper.countByLessonAndStudent(lessonId, studentId);
if (count > 0) {
throw new BizException("您已预约过该课时");
}
// 3. 乐观锁更新已预约人数
int rows = lessonPlanMapper.increaseBookedCount(lessonId, lesson.getBookedCount());
if (rows == 0) {
throw new BizException("该课时名额已满，预约失败");
}
// 4. 创建预约记录
Booking booking = new Booking();
booking.setLessonId(lessonId);
booking.setStudentId(studentId);
booking.setStatus(0);
booking.setBookingTime(LocalDateTime.now());
bookingMapper.insert(booking);
return convertToVO(booking);
}
increaseBookedCount 的SQL设计如下：
sql复制UPDATE lesson_plan
SET booked_count = booked_count + 1
WHERE id = #{lessonId} AND booked_count = #{expectCount} AND booked_count < max_students
当更新行数为0时，说明并发请求已经修改了 booked_count，此时它不再是之前查询到的值，或者已经到达容量上限，预约就应当失败。乐观锁的好处是只在写冲突的时候才阻塞，在读多写少的预约场景下比悲观锁性能好不少。
4.3 教练排课看板：后端数据组装与前端展示方案
排课系统做完接口之后，运营最需要的是一个可视化的课表界面。开发阶段可以做一个教练课表查询接口，按周为单位返回某位教练的课时计划，前端再配合日历组件渲染。
后端接口设计上，返回的数据结构建议按天聚合：
json复制{
"coachId": 1,
"coachName": "张教练",
"weekStart": "2025-06-02",
"weekEnd": "2025-06-08",
"days": [
{
"date": "2025-06-02",
"lessons": [
{
"lessonId": 101,
"courseName": "科目二",
"startTime": "09:00",
"endTime": "09:50",
"status": 0,
"bookedCount": 2,
"maxStudents": 3
}
]
}
]
}
Service层的组装逻辑很简单，先查出教练本周所有课时记录，再按日期分组。理论上一步 GroupingBy 就能搞定，不需要写冗长的循环。
前端展示方案我推荐用开源的 FullCalendar 组件，它对日历视图的支持很完善，可以按周渲染课表，拖拽调整时间。不过拖拽调整本质上是"取消旧课+创建新课"的组合操作，需要后端提供对应的接口，这一点在排课系统开发里面可以做成进阶需求。
如果不想引入大型日历组件，更轻量的方案是用 Ant Design Vue 或 Element UI 的日历组件，配合简单的卡片渲染，也能达到运营可用的效果。关键不是组件多炫，而是数据加载和刷新要快、清晰，运营看到自己的课表更新要及时。
5. 常见问题与排查实录
5.1 并发超卖的另类场景：同一学员抢同一节课
学员A和学员B同时发起预约，数据库的 uk_lesson_student 约束只能保证同一个学员同一时刻只预约一次，但两个不同学员同时抢最后一个名额，必须在 booked_count 上做控制。上面提到的乐观锁方案已经解决了这个问题，但有一个衍生场景很值得注意：如果学员A开了两个浏览器标签页同时点击预约，两个请求都会通过"是否已预约"的检查，然后同时进入 increaseBookedCount，其中一个会成功，另一个会因为唯一约束失败而回滚。现象是用户报告"明明预约成功了，刷新却显示没约上"。
这个问题的根因是"检查预约状态"和"创建预约记录"之间存在时间窗口。解决办法是在 booking 表的 uk_lesson_student 唯一约束之外，再在业务层面加一层防护：使用 Redis 的 SETNX 命令，以 lesson:book:userId:lessonId 为 key 做预占，抢到锁的才允许继续走预约流程。这样即使用户连点多次，也只有第一次请求能进入预约流程。
5.2 时区与时间格式的坑
排课系统里全是时间字段，时区问题防不胜防。我在项目里用的是 LocalDate 存上课日期、LocalTime 存开始和结束时间、LocalDateTime 存创建和更新时间。这三个类型在 Java 8 之后都是推荐用法，配合 MySQL 的 DATE、TIME、DATETIME 类型完全匹配。
需要注意的点有三个：
第一，JDBC 连接串必须加上服务器时区，否则驱动会按 JVM 默认时区解析，跨时区部署时会出问题。推荐配置：
yaml复制spring:
datasource:
url: jdbc:mysql://localhost:3306/schedule_db?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false
第二，前后端传参一定要统一格式。用 LocalDateTime 接收前端传来的时间字符串时，需要在 application.yml 里配置全局的 JSON 解析格式，或者直接约定前端传 yyyy-MM-dd HH:mm:ss 字符串。
第三，如果将来要对接云端服务或者做多校区跨时区部署，建议在数据库统一存 UTC 时间，在服务端转成当地时区展示。目前中小项目不需要这个复杂度，但设计数据模型时时间字段的语义要写清楚，是北京时间还是UTC，避免后续踩坑。
5.3 性能瓶颈与优化方向
排课系统的数据量一般不会特别大，一个中型培训机构一年课程记录也就几万条，在正常的索引策略下，查询性能完全不是问题。容易出现性能问题的反而是代码层面，典型就是 MyBatis 的 N+1 查询问题。
比如查询一周课表时，先查出课程计划列表，然后在循环里逐条查课程名称、教练姓名，每一条记录都发一条SQL，课表有100条记录就会发出200多条SQL。优化方案有两种：一是 Service 层循环前先查出所有需要的课程和教练信息，在内存中做 map 匹配；二是直接用联表查询，把课程名称和教练姓名拼进返回结果。
另外，如果运营后台要统计全机构教练一个月的课时数，这种报表类查询建议单独建一个统计Mapper，用聚合SQL直接算，不要在业务代码里循环遍历所有记录。
6. 源码的二次开发与扩展建议
拿到一版排课系统源码或者照着本文的代码写完初始版本之后，想让它更贴合真实业务，可以考虑几个扩展方向。第一个是增加"休息日"和"请假"功能，教练可以提交请假申请，系统自动把该日的排课时段置灰，已预约学员收到调整通知。第二个是增加"课程周期模板"，对于固定的每周课程，运营只需要排一次，系统自动按周生成课程计划，不用每周手动重复操作。第三个是增加基础的统计报表，比如课时完成率、学员取消率、教练闲置时长，这些数据直接反映机构运营情况，也可以做成简单的看板页面。
扩展功能的关键是要守住一个原则：新功能不能破坏原有数据的正确性。以"请假"功能为例，教练提交请假申请之后，系统必须处理该日所有已排课时，要么自动取消、要么调整到其他时段，不能允许"请了假但课程依然正常展示"的矛盾状态存在。任何扩展功能都要先把状态流转设计清楚，再落地编码。
7. 结语：排课系统开发的一点体会
排课系统这类业务项目，技术上并不高深，难点全在对业务规则的理解和并发场景下数据一致性的把控。很多同学拿到项目需求先急着写代码，结果写完一版才发现业务规则没梳理清楚，返工成本非常高。我的习惯是先花一天时间把状态机画成表格、把时间区间重叠的边界条件写清楚，再开始建表和写代码，这样后面基本不会有大改。
还有一个小技巧想分享给大家：排课系统里所有涉及状态的地方，建议统一用枚举类管理，不要在代码里散落一堆 magic number。比如课程状态 0待开始 1进行中 2已完成 3已取消，如果都用魔法数字，业务代码读起来费劲，改需求的时候还容易漏改。用枚举类封装之后，编译期就能发现非法状态，代码可维护性提升一个档次。根据我的实测，把这些细节做好，项目交付之后维护阶段的省心程度完全不一样。