Java实战项目：从零开发排课系统，搞定Spring Boot与冲突检测

之前带过几期Java实训班，每次到排课环节就头疼，手工排课表的Excel传来传去，冲突不断。后来干脆带着学员从零写了一个排课系统，把排课、教室预约、教师配比、课程冲突检测全流程跑通。今天就用这个项目当例子，聊一聊Java教练培训里怎么把“排课系统”这个经典业务场景，拆成一份可落地、能复用、还能写进简历的源码开发指南。

这套排课系统适合正在学Java Web开发的初中级学习者，也适合准备面试时想拿业务项目当敲门砖的人。它不像电商、秒杀那么俗套，但涉及的分表设计、冲突算法、状态机流转、权限控制，都是面试官真正会追问的东西。本文会把技术选型、表结构、核心算法、避坑经验一次讲透，能直接照着敲。

1. 项目整体设计与技术选型解析

排课系统听起来简单，无非就是“哪个班、哪个老师、哪个教室、什么时间上课”，但真做起来，业务复杂度一点也不小。一个培训机构可能同时有几十个班、上百个老师、多个校区、多个教室，还有寒暑假密集排课、临时调课、补课、试听插入等场景。

1.1 为什么选 Spring Boot + MyBatis-Plus 这套组合

现在Java后端的主流组合，Spring Boot 3.x + MyBatis-Plus 3.5.x + MySQL 8.x 基本是培训班里的标配。选这套不是因为它最新，而是因为它够稳、资料多、学员上手快。

Spring Boot解决的是配置地狱问题，内嵌Tomcat让项目能一键启动。MyBatis-Plus则把单表CRUD简化到极致，学员不需要写一堆重复的XML，BaseMapper自带的方法够用，复杂的多表关联再手写SQL。相比JPA，MyBatis-Plus对学员来说更“看得见摸得着”，SQL执行了什么一目了然，调试起来也容易解释。

前端我建议用Vue 3 + Element Plus，不要上太复杂的前端工程化方案。排课系统本质上是一个后台管理系统，核心界面就三个：排课操作台、冲突提示面板、课程表视图。Element Plus的日历组件和表格组件能直接复用，学员把精力放在业务逻辑上就好。

1.2 核心需求拆解：排课到底排什么

在动手写代码前，先把业务需求理清楚。一套完整的排课流程包含下面几个环节：

1. 基础数据维护：班级、教师、教室、课程、上课时段。
2. 排课规则配置：一个班一周上几节课，每节课多长，教师一周最多多少课时。
3. 排课操作：选择一个班级，为它分配课程、教师、教室、时间段。
4. 冲突检测：同一时间、同一教师不能出现在两个教室；同一教室不能同时被两个班占用。
5. 排课结果展示：按班级维度查看课表、按教师维度查看课表、按教室维度查看占用情况。
6. 调课与补课：课程取消、换时间、换教室，需要保留操作日志。

这六块里，前两块是基础，第三四块是核心，最后两块是人性化的加分项。很多学员上来就写排课页面，结果没有冲突检测，排出来乱七八糟。先把需求拆清楚，后面对照着做功能点才不会漏。

1.3 技术栈版本与工程结构规划

我建议用一套明确的版本组合，避免学员在依赖冲突上浪费时间：

• JDK 17（LTS版本，Spring Boot 3.x要求的最低版本）
• Spring Boot 3.2.x
• MyBatis-Plus 3.5.5
• MySQL 8.0.x
• Redis 6.x（可选，用于缓存排课结果和登录token）
• Sa-Token或Spring Security（权限控制，建议Sa-Token，对初学者友好）
• Vue 3 + Vite + Element Plus + Axios

工程结构采用经典的分层结构，前两周学员可能会疑惑为什么类要分这么多层，等做到权限控制和事务回滚时才能体会好处：

code复制schedule-system/
├── src/main/java/com/example/schedule/
│   ├── controller/       # 接口层
│   ├── service/          # 业务逻辑层
│   ├── mapper/           # 数据访问层
│   ├── entity/           # 实体类
│   ├── dto/              # 传输对象
│   ├── vo/               # 视图对象
│   ├── config/           # 配置类
│   ├── common/           # 通用返回结果、异常处理
│   └── ScheduleApplication.java

这种结构不是什么高深设计，但它能帮学员养成“请求进来先找Controller，业务逻辑放Service，数据库操作走Mapper”的思维习惯。后面接Redis、接消息队列、做微服务拆分，都是在这个基础上演化的。

2. 排课系统的数据库设计与核心表结构

表结构设计是一套系统的地基。很多学员习惯写代码写到哪里，再临时加字段，结果后期数据乱了、关联对不上，返工成本极高。排课系统建议从第一周就把表设计定稿，后面迭代尽量只加字段、不改结构。

2.1 核心表设计：班级、教师、教室、课程

先说基础表。这一部分看起来简单，但有几个字段容易忽略，我在源码注释里都会标红提醒。

班级表（t_class）

• id：主键
• class_name：班级名称，比如“Java基础班2024-01期”
• grade_level：学习阶段，比如“基础”“进阶”“就业”
• student_count：班级人数，排课时用来校验教室容量
• start_date、end_date：开班时间、结课时间
• status：状态，1-招生中，2-上课中，3-已结课
• deleted：逻辑删除标记

教师表（t_teacher）

• id：主键
• teacher_name：姓名
• specialty：擅长方向，比如“Java基础”“分布式”“项目实战”
• max_hours_per_week：每周最大课时数，用于排课时的负载均衡
• status：1-在职，0-休假/离职

教室表（t_classroom）

• id：主键
• classroom_name：比如“A栋302”
• capacity：最大容纳人数
• has_projector、has_whiteboard：设备标记
• classroom_type：类型，普通教室、机房、实训室
• status：是否可用

课程表（t_course）

• id：主键
• course_name：课程名称
• course_hours：总课时
• course_type：理论课/实训课，不同课程可能对教室类型有要求

在实际开发中，我还会加一张校区表t_campus，用campus_id做数据的逻辑隔离。不是所有项目都需要多校区，但加上这个字段，学员能理解“数据隔离”的意义，面试被问到“你怎么设计多租户数据隔离”时，也有话可说。

2.2 排课记录表与时间片设计

排课记录表是整个系统的核心，所有业务规则最终都落在这张表上。

code复制t_schedule
- id
- class_id：班级ID
- course_id：课程ID
- teacher_id：教师ID
- classroom_id：教室ID
- schedule_date：上课日期
- start_time：开始时间，比如 14:00
- end_time：结束时间，比如 16:00
- week_number：第几周（学期内第N周上课）
- status：1-已排，2-已上课，3-已取消，4-已调课
- operator_id：操作人ID
- create_time / update_time

这里我特意用了schedule_date + start_time + end_time，而不是用weekday（星期几）。原因很简单：寒暑假班和全日班经常不按周循环走，按具体日期排更灵活。如果为了省事只存星期几，后面处理节假日调休、临时补课时，会非常痛苦。

时间片的问题也得提前想清楚。每个班每天上几个时段，每个时段多长，我建议做成可配置的字典表（t_time_slot）：

code复制t_time_slot
- id
- slot_name：上午第一节
- start_time：08:30
- end_time：10:00
- slot_index：上下午标识

这样设计的最大好处是，如果校区调整作息时间，只需要改字典表，不需要动排课代码。学员能在这个点上理解“参数配置化”的价值，这也是面试加分项。

2.3 索引设计与数据一致性考虑

排课完成之后，最频繁的查询是：“某教师某天的课表”“某教室某时段是否空闲”“某班级一周的课表”。这些查询条件基本都落在teacher_id/classroom_id/schedule_date/start_time这几个字段上，所以联合索引必须建好。

我建议至少建这几个索引：

sql复制ALTER TABLE t_schedule ADD INDEX idx_class_date (class_id, schedule_date);
ALTER TABLE t_schedule ADD INDEX idx_teacher_date (teacher_id, schedule_date);
ALTER TABLE t_schedule ADD INDEX idx_classroom_date (classroom_id, schedule_date);

索引不是越多越好，但排课表这三个维度的查询频率极高，没有索引会出现全表扫描，学员用测试数据不觉得慢，一旦数据量上到几万条，性能差异立刻出来。

数据一致性方面，核心是避免“同一教师同时排到两节课”这类脏数据。除了在代码层做冲突检测，我还会在数据库层面加一个唯一约束兜底：

sql复制ALTER TABLE t_schedule ADD UNIQUE KEY uk_teacher_time (teacher_id, schedule_date, start_time);

有了这道约束，哪怕代码层漏了校验，数据库也会抛异常拦住，不至于静默产生冲突数据。这个“双重保险”的思路，我会反复跟学员强调，这是生产环境和毕设项目的分水岭。

3. 排课冲突检测算法：核心难点与实现思路

排课系统最核心的技术难点就是冲突检测。很多初学者觉得冲突检测很简单，查一下有没有重叠就行。但实际场景中，要考虑同一教师跨教室冲突、教室容量不足、课程类型不匹配、教师每周课时上限等一大堆约束。

3.1 冲突检测的维度拆解

排课的时候，一条新排课记录至少需要做四个维度的校验：

1. 教师时间冲突：教师在同一时间只能在一间教室上课。
2. 教室时间冲突：教室在同一时间只能被一个班占用。
3. 班级时间冲突：班级在同一时间只能上一门课。
4. 资源约束校验：教室容量 ≥ 班级人数，教室类型匹配课程类型（实训课不能排到普通教室），教师剩余周课时 ≥ 本次课时。

前三个是硬性约束，必须严格校验，否则数据就是错的。第四个是软性约束，可以作为提示给操作人员，由人来判断是否需要坚持排课。

3.2 时间重叠判断的两种写法

判断两条课程是否时间重叠，看起来简单，其实容易写错。两条记录A和B，A的起止时间是aStart和aEnd，B的起止时间是bStart和bEnd。

判断重叠的最简写法是：

java复制// 如果A在B之前结束，或者B在A之前结束，说明完全不重叠
if (aEnd <= bStart || bEnd <= aStart) {
    // 不冲突
} else {
    // 冲突
}

这个判断逻辑用生活例子类比就是：你去酒店订会场，只要你的开会结束时间早于别人开始布置时间，或者你的开始时间晚于别人收拾完的时间，你们就不会打照面。

还有一种写法是用区间交集：

java复制if (Math.min(aEnd, bEnd) > Math.max(aStart, bStart)) {
    // 冲突
}

两种写法效果一样，但我会让学员必须理解第一种写法，因为它在SQL里更好用。写SQL查冲突时，只需要一条条件就能命中：

sql复制SELECT COUNT(*) FROM t_schedule
WHERE teacher_id = 1001
  AND schedule_date = '2024-06-17'
  AND start_time < #{endTime}
  AND end_time > #{startTime}

这段SQL的意思就是：找出所有“开始的比本次结束早，且结束的比本次开始晚”的记录。只要COUNT大于0，说明这个教师这个时间段已经有课了。

3.3 冲突检测服务的完整实现

在service层，我会把冲突检测抽成一个独立的ScheduleValidator组件。这样排课、调课、批量导入三个入口都可以复用同一套校验逻辑，不用各写各的。

java复制@Component
public class ScheduleValidator {

    public void validate(ScheduleCreateDTO dto) {
        // 1. 教师时间冲突
        checkTeacherConflict(dto);
        // 2. 教室时间冲突
        checkClassroomConflict(dto);
        // 3. 班级时间冲突
        checkClassConflict(dto);
        // 4. 资源软约束
        checkCapacity(dto);
        checkCourseType(dto);
        checkTeacherLoad(dto);
    }

    private void checkTeacherConflict(ScheduleCreateDTO dto) {
        LambdaQueryWrapper<Schedule> wrapper = new LambdaQueryWrapper<>();
        wrapper.eq(Schedule::getTeacherId, dto.getTeacherId())
               .eq(Schedule::getScheduleDate, dto.getScheduleDate())
               .ne(dto.getId() != null, Schedule::getId, dto.getId())  // 调课时排除自身
               .lt(Schedule::getStartTime, dto.getEndTime())
               .gt(Schedule::getEndTime, dto.getStartTime())
               .ne(Schedule::getStatus, ScheduleStatus.CANCELED);
        long count = scheduleMapper.selectCount(wrapper);
        if (count > 0) {
            throw new BizException("该教师在此时间段已有课程安排");
        }
    }

    // 教室、班级的检测逻辑类似，这里省略重复代码
}

这里有个细节非常关键：调课的时候，同一节课修改时间，要排除自身记录。否则你只是想给这节课换个时间，结果把原时间的自己当成了冲突对象，怎么改都会报错。给学员讲到这里时，我会让他们自己踩一遍这个坑，记住了就不会忘。

状态过滤也很重要。已经被取消的课程不应该参与冲突校验，否则一个取消的课程会一直占着时间，导致该时间段无法排新课。这个问题在初版代码里很容易漏掉。

3.4 批量排课与自动推荐时间的思路

做完整版排课系统时，除了手工逐条排课，我还会让学员做一个“智能推荐下一个可用时间”的功能。这个功能听起来高级，其实背后的算法很简单：遍历预先配置好的时间片，逐个查询冲突，返回第一个没有冲突的时间段。

伪代码如下：

java复制public TimeSlot suggestNextSlot(ScheduleCreateDTO dto) {
    List<TimeSlot> slots = timeSlotMapper.selectList(null);
    for (TimeSlot slot : slots) {
        ScheduleCreateDTO test = dto.clone();
        test.setStartTime(slot.getStartTime());
        test.setEndTime(slot.getEndTime());
        try {
            validator.validate(test);
            return slot;  // 当前时间片可用
        } catch (BizException e) {
            // 冲突，继续尝试下一个
        }
    }
    return null;  // 所有时间片都不可用
}

这就是一个典型的“贪心算法”：按顺序找第一个可用解，不追求全局最优。实际业务中，排课管理员通常只需要“帮我找一个可用的时间段”，并不需要复杂的最优化计算。先把这个实现方案讲明白，再延伸讨论如果要做“最优排课”可以考虑哪些算法，学员的理解才会深入。

如果有学员感兴趣，可以延伸聊一下遗传算法排课的概念，但要明确告诉他们：真实培训机构的排课系统大多不需要这么复杂，贪心+人工微调就是最实用的方案。不要为了炫技把系统搞复杂。

4. 实操过程与核心环节实现

从零搭建整个排课系统，一周时间可以从环境准备做到排课接口联调通。下面按实操顺序过一遍关键环节，跟着做能少踩很多坑。

4.1 项目初始化和数据库初始化

第一步是创建Spring Boot项目。我用的是Spring Initializr官网生成基础工程，选好Spring Web、MySQL Driver、Lombok这几个依赖，下载后导入IDEA。

pom.xml里面需要额外引入MyBatis-Plus依赖。这里有个坑：Spring Boot 3.x必须用MyBatis-Plus的mybatis-plus-spring-boot3-starter，老版本的mybatis-plus-boot-starter只适配Spring Boot 2.x，直接引老版本会出现Mapper扫描不到的问题。

xml复制<dependency>
    <groupId>com.baomidou</groupId>
    <artifactId>mybatis-plus-spring-boot3-starter</artifactId>
    <version>3.5.5</version>
</dependency>

数据库初始化脚本建议用一张init.sql搞定，包含所有表的建表语句和演示数据。对初学者来说，有演示数据非常关键，否则接口写完返回空列表，页面一片空白，根本分不清是前端问题还是后端没数据。

4.2 后端接口实现的完整清单

排课系统的后端接口不需要太复杂，核心就是一套Restful风格的接口：

在排课接口的实现上，我一直强调“事务”概念。排课不只是插入一条t_schedule记录，还可能要同时记录操作日志、更新班级的已排课时数。这些操作必须放在同一个事务里，要么全成功，要么全失败。

java复制@Transactional(rollbackFor = Exception.class)
public ScheduleCreateResult createSchedule(ScheduleCreateDTO dto) {
    // 1. 冲突校验
    scheduleValidator.validate(dto);
    // 2. 插入排课记录
    Schedule schedule = convertToEntity(dto);
    scheduleMapper.insert(schedule);
    // 3. 写入操作日志
    scheduleLogService.log(dto, "排课");
    // 4. 返回结果
    return ScheduleCreateResult.success(schedule);
}

有几个学员在这个环节问过：为什么加了一个@Transactional，事务注解就生效了？其实是因为Spring的声明式事务基于AOP代理，调用方必须从外部调用这个被代理的方法。如果同一个类内部方法互调，事务是不会生效的。这个知识点面试时也经常会问到“事务失效的场景”。

4.3 前端页面与日历课表渲染方案

前端用Vue 3 + Element Plus做管理界面，最核心的是课表展示页。Element Plus有现成的el-calendar组件，但直接用在课表场景不太好用，因为课表需要以“星期几”为列、以“第几节”为行，像Excel表格一样展示。

我的建议是直接用el-table来模拟课表布局：

• 每一行代表一个时间段（比如08:30-10:00）
• 每一列代表星期一到星期日
• 单元格里放课程卡片，显示课程名、班级、教师、教室

后端返回的数据格式做成一个二维Map：

json复制{
  "period_1": {
    "MON": {"courseName": "Java基础", "teacherName": "王老师", "classroomName": "A302"},
    "TUE": null
  },
  "period_2": {
    "MON": null,
    "TUE": {"courseName": "MySQL", "teacherName": "李老师", "classroomName": "B101"}
  }
}

前端拿到这个结构，遍历表格的行列，直接把课程卡片填充进去。这个方案的优点是表格线和课程卡片天然对齐，视觉上很清楚，调整起来也不复杂。

4.4 冲突提示与前端拦截体验优化

后端做了冲突检测就够了吗？不够。如果用户辛辛苦苦填完一个表单，点击提交才提示“该教师已有课程”，体验是很差的。好的做法是：在用户选择了教师、日期、时间段之后，立刻异步请求后端校验一次冲突，前端在提交按钮上方显示绿色的“可排”或红色的“冲突提示”。

这个“提前校验”接口和真正的排课校验是同一套逻辑，只是多了个checkOnly模式，只校验不保存。

java复制@PostMapping("/api/schedules/check")
public Result<Void> check(@RequestBody ScheduleCreateDTO dto) {
    scheduleValidator.validate(dto);
    return Result.success();
}

前端在表单变更时防抖调用这个接口，比如用户停止操作300毫秒后再发起请求，避免在输入过程中频繁请求后端造成压力。这一个细节会让整个系统用起来“很专业”，但很多版本的源码都没有做。

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

学员在开发排课系统的过程中，遇到的问题翻来覆去就那么几个。我把十年的带班经验里的高频问题整理成速查表，大家可以直接对照排查。

5.1 高频报错与经典bug清单

问题一：时间比较结果不正确，明明冲突了却提示不冲突

最常见的原因是：前端传的时间是字符串，比如"14:00"，数据库存的也是time类型，但实体类里用的是LocalTime。如果实体类用了String接收，比较时就是按字典序比较字符串，而"9:00"和"09:00"的字典序结果完全不同。解决方法是统一使用LocalTime类型接收时间字段，或者在SQL中使用TIME()函数做转换。

问题二：排课数据重复，同一个教室同时排了两门课

这是典型的校验漏了状态过滤。我在冲突检测SQL里加了.ne(Schedule::getStatus, ScheduleStatus.CANCELED)，如果漏掉这个条件，被取消的课程还在占用时间，新课程排不进去；反过来，如果漏掉了schedule_date条件，会把不同日期的记录也当成冲突，导致相同时间段永远排不了课。

问题三：部署到服务器后，中文乱码

这个多数是MySQL连接串少了characterEncoding=utf8参数。排查思路是：本地开发环境正常，部署到Linux后乱码，优先检查连接字符串和数据库、表的字符集设置，三者必须保持一致。

问题四：前端课表表格加载慢

通常是因为前端一次性请求了所有数据。后端的接口应该支持按周查询（传一个起始日期和结束日期），一次只查一周的数据。所有课程数据一次性返回，看起来方便，但数据量一大就卡。

问题五：MyBatis-Plus自动填充不生效

如果用了@TableField(fill = FieldFill.INSERT)来自动填充创建时间，但插库后create_time是null，大概率是没写MetaObjectHandler实现类。这是配置性的小问题，但初学时很容易漏。

5.2 排查流程方法论：从现象到根因

我希望学员掌握的不是“搜报错”，而是系统性的排查思路。写代码调试的时候，我建议按这个顺序走：

1. 先看控制台日志中的SQL语句，确认传给数据库的参数是否符合预期。
2. 再拿着SQL直接到数据库客户端里执行一遍，看返回结果是否正确。这一步能快速区分问题出在SQL写错还是业务逻辑写错。
3. 如果SQL正确但接口返回异常，再检查Service层的业务逻辑，特别是条件判断。
4. 最后再看Controller层面的参数接收，确认前端传过来的数据格式是否和后端DTO一致。

这个思路可以概括成一句话：从前端到数据库，逐层往深处定位问题，而不是看到报错就在最近的一层瞎改。

5.3 如何优雅地处理跨天排课与午休时间

排课系统还有一个容易忽略的细节：跨天排课和午休问题。比如一个机房实训课，需要从08:30一直排到12:00，中间跨了四个时间段。简单的时间冲突检测会把“08:30-12:00”和“10:20-12:00”判断为冲突，这没问题。但如果排课管理员需要一个午休时间不排课、晚饭时间也不排课，就需要在时间片字典表里设置“休息”标记，并且排课推荐逻辑要自动跳过这些时段。

处理方法很直接：在t_time_slot表增加一个is_active字段，休息时间片标记为0。推荐时间算法里只遍历is_active=1的时间片。这再次印证了，很多看起来复杂的业务规则，通过合理的表结构设计，能在很早期就化解掉。

6. 从源码到简历：排课系统的几个加分项

既然做了一套完整的排课系统源码，就不该只停留在“能跑”阶段。面试的时候，真正能打动面试官的点往往在源码细节里。

6.1 如何把排课系统的源码变成面试谈资

排课系统是典型的管理系统，面试官不会觉得它有多高的技术含量，但你可以主动往深了引导。比如：

• 引导方向一：冲突检测的并发问题。如果两个管理员同时给同一个教师排同一时间段，事务和唯一索引如何兜底？这就是一个天然的“并发安全问题”讨论场景。
• 引导方向二：调课操作。调课不只是update一条记录，还需要考虑操作日志、原课次状态流转、班级课表刷新。这是一个“状态机”的应用场景。
• 引导方向三：课表数据量大了怎么办。如果几千条记录查询就很慢，该怎么优化。索引怎么设计，要不要做缓存，Redis缓存的是课表对象还是SQL结果。这些都能聊开。

这样一套组合拳打下来，面试官会看到你不只是会“增删改查”，还会做数据建模、并发控制、缓存设计，这比背八股文强得多。

6.2 排课系统还可以扩展什么方向

如果想让这个项目更有区分度，可以尝试扩展以下几个方向，每加一个功能，项目的深度和价值就上一个台阶：

• 自动排课接口：接入班级的完整课表需求，由系统自动计算出一版没有冲突的课程安排。
• 调课审批流：补课或调课需要教学主管审批，加一张审批表，请求时状态是“待审批”，审批通过后才生效。
• 教师端小程序：教师请假时，系统能自动推送请假时间段内的冲突课程名单。
• 数据可视化：统计各教室利用率、教师课时负载、课程完成进度，用ECharts做几张报表页面出来。

有余力的学员可以挑其中一个方向做深入实现。做透一个扩展方向，比做十个半成品功能更值钱。

6.3 学习顺序与源码阅读建议

最后说说怎么高效地利用这份排课系统源码学习。

我建议的顺序是：先看数据库表结构，理解整个系统的数据模型；再看Service层的核心业务逻辑，重点看冲突检测和排课事务；接着看Controller层，反推前端接口是怎么对接的；最后才是去看前端页面代码。

看源码时不要只看不动手，一定要基于源码做二次开发。可以试着给系统加一个“按教室利用率排序展示”的功能，也可以加一个“教师课表导出Excel”的功能。只有亲手改过代码，源码的价值才会变成你自己的能力。

根据我带训的经验，排课系统这个项目做得好的学员，通常在后面的实战项目里表现也不会差。因为它是个特别完整的业务系统，麻雀虽小五脏俱全，把CRUD做到极致、把业务规则理清楚、把并发和事务的坑填平，对初级Java开发者来说，这就是最好的成长路径。