Spring Boot智能排课系统源码：冲突检测与课表生成实战

简介：这是一套基于Spring Boot框架的智能排课系统完整源码，面向计算机相关专业学生、课程设计开发者及需要搭建教务管理平台的院校技术人员。系统采用BS结构与Web服务模式，支持用户管理、课程管理、自动化排课、学生选课及资讯公告发布等核心模块，管理员可创建教师账号、录入课程安排，系统依据教师、教室与时间要求智能分配课表，学生则能在线浏览并选择课程。压缩包共673个文件，约16.99MB，以Vue前端组件、Java后端源码、JPG与PNG界面截图、class与jar依赖包、JS脚本及JSON、XML配置文件为主，另含少量SQL脚本与说明文档，前后端分离结构清晰。目前已有101人学习下载。读者可据此获得一套可直接运行调试的排课系统参考实现，理解智能排课算法与前后端交互逻辑，适合作为毕业设计或课程作业的二次开发基础。

1. 一份能跑起来的智能排课系统源码，到底解决了什么问题

如果你带过计算机专业的课程设计，或者正被"排课"这件事折磨过，应该懂那种感觉：教务老师拿着 Excel 反复拖拽，冲突检测全靠肉眼，一个教室被两门课同时占用，两个老师被排到同一时间段，改一处牵动全身。这份基于 Spring Boot 框架的智能排课系统源码，就是冲着这个场景来的——它把"课程、教师、班级、教室、时间段"这几类约束抽象成数据模型，用后端算法自动生成一张尽量无冲突的课表，再通过接口把结果吐给前端展示。

它适合三类人：一是做课程设计、毕业设计的学生，需要一套结构完整、能讲清楚技术栈的 Java Web 项目；二是想学 Spring Boot 分层架构（Controller-Service-Mapper）的初学者，这套代码的目录结构比较规整，适合当模板拆；三是需要快速搭一个排课原型的小团队，可以在这套骨架上改业务规则。源码包本身是完整的工程压缩包，导入 IDE 就能编译运行，不需要你从零搭环境。下面我按"它是什么、怎么跑起来、坑在哪、怎么改"的顺序，把这份资源拆开讲。

2. 技术栈与工程结构：Spring Boot 分层怎么落到排课业务上

2.1 为什么排课系统适合用 Spring Boot 这套组合

排课系统的本质是"约束满足 + 数据增删改查"，业务逻辑集中在冲突检测和课表生成，外围全是标准的 CRUD。这种"重逻辑、轻并发"的特征，恰好是 Spring Boot + MyBatis 的舒适区。Spring Boot 负责把 Web 层、依赖注入、事务管理这些样板代码压到最低，MyBatis 负责把课程、教师、教室这些实体和数据库表映射起来，中间用 Service 层承载排课算法。

常见做法是：Controller 只做参数校验和结果封装，Service 里写排课核心逻辑，Mapper 只负责 SQL。这样分层的好处是，当你想换一套排课算法时，只动 Service，不碰 Controller 和 Mapper。这套源码基本遵循了这个约定，所以它不只是"能跑"，而是"能改"——对课程设计来说，能改比能跑更值钱，因为答辩老师一定会问你"如果要加一个约束条件，你改哪里"。

选型上还有一点值得说：为什么不用纯 JDBC 或者 JPA？纯 JDBC 写起来太啰嗦，一个查询要手动关连接、处理结果集；JPA 虽然省事，但排课里经常要写复杂的关联查询（比如"查某教师在某时间段是否已有课"），JPA 的自动生成 SQL 在这种场景下反而不好控制。MyBatis 的 XML 映射让你能精确控制每条 SQL，这对排课这种查询密集的业务更友好。

2.2 工程目录与关键文件清单

拿到源码包后，先别急着运行，花五分钟把目录结构看一遍，后面排错会快很多。典型的 Spring Boot 排课工程结构如下：

这份清单不是让你背，而是让你在报错时能快速定位：报"找不到 Mapper"就去查mapper目录和application.yml里的扫描路径；报"表不存在"就去查实体类和数据库表名是否对得上。排课系统的实体关系比一般 CRUD 复杂，课程和教师是多对多，课程和班级是多对多，课表是这些关系的交叉结果，所以实体类里的字段设计直接决定了后面算法好不好写。

2.3 从零把工程跑起来：环境、配置、启动三步

第一步，确认本地环境。JDK 8 或 11（Spring Boot 2.x 对这两个版本支持最稳），Maven 3.6+，MySQL 5.7 或 8.0。如果你用的是 IntelliJ IDEA 社区版，导入 Maven 工程后它会自动下载依赖，社区版对 Spring Boot 的支持虽然不如旗舰版，但跑起来完全没问题，只是没有那些自动提示。

第二步，建库建表。源码包里一般会带一个.sql文件，先把它导入 MySQL：

# 登录 MySQL 后执行，库名按 sql 文件里的实际名字来 mysql -u root -p CREATE DATABASE schedule_db DEFAULT CHARACTER SET utf8mb4; USE schedule_db; SOURCE /你的路径/schedule_db.sql;

这里有个细节：utf8mb4而不是utf8，因为课程名、教师名里可能有生僻字或特殊符号，utf8在 MySQL 里只支持三字节，遇到四字节字符会报错。导入完成后用SHOW TABLES;确认表都建好了，重点看有没有course、teacher、classroom、schedule这几张核心表。

第三步，改配置文件并启动。打开application.yml，把数据库连接改成你自己的：

spring: datasource: url: jdbc:mysql://localhost:3306/schedule_db?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: 你的密码 driver-class-name: com.mysql.cj.jdbc.Driver server: port: 8080 mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.example.schedule.entity

serverTimezone=Asia/Shanghai这个参数别省，MySQL 8.0 不加时区会报The server time zone value is unrecognized，这是新手最常见的翻车点。mapper-locations指向 XML 映射文件的位置，如果启动时报Invalid bound statement，八成是这里路径写错了。配置改完，在 IDEA 里找到主启动类（带@SpringBootApplication注解的那个），右键 Run，控制台出现Started ... in x seconds就说明起来了。浏览器访问http://localhost:8080看能不能打开首页。

3. 排课核心逻辑：冲突检测与课表生成怎么实现

3.1 约束模型：硬约束和软约束要分开处理

排课问题在算法上属于 NP 难问题，想一次求出全局最优解不现实，工程上的通行做法是"先满足硬约束，再优化软约束"。硬约束是绝对不能违反的：同一教师同一时间段不能上两门课，同一教室同一时间段不能排两门课，同一班级同一时间段不能有两门课。软约束是可以妥协的：尽量不把课排在晚上，尽量让教师连续上课，尽量均匀分布。

这套源码的 Service 层里，冲突检测通常是一个独立方法，输入是"待排的课程 + 时间段 + 教室 + 教师"，输出是布尔值或冲突列表。理解这个模型，你才能看懂代码为什么这么写，也才知道加约束时该往哪加。常见做法是把硬约束写成if判断链，软约束做成评分函数，排课时优先选评分高的方案。

3.2 冲突检测的代码实现与参数说明

下面是一段典型的冲突检测逻辑，我按源码里常见的写法还原，你可以对照自己的工程看：

// 检查一条排课记录是否与已有课表冲突 public List<String> checkConflict(Schedule newSchedule) { List<String> conflicts = new ArrayList<>(); // 1. 教师冲突：同一教师、同一时间段、同一天 int teacherConflict = scheduleMapper.countByTeacherAndTime( newSchedule.getTeacherId(), newSchedule.getDayOfWeek(), newSchedule.getTimeSlot()); if (teacherConflict > 0) { conflicts.add("教师在该时间段已有课程"); } // 2. 教室冲突 int roomConflict = scheduleMapper.countByRoomAndTime( newSchedule.getClassroomId(), newSchedule.getDayOfWeek(), newSchedule.getTimeSlot()); if (roomConflict > 0) { conflicts.add("教室在该时间段已被占用"); } // 3. 班级冲突 int classConflict = scheduleMapper.countByClassAndTime( newSchedule.getClassId(), newSchedule.getDayOfWeek(), newSchedule.getTimeSlot()); if (classConflict > 0) { conflicts.add("班级在该时间段已有课程"); } return conflicts; }

逻辑说明：这个方法把三类硬约束拆成三个独立的查询，每个查询用count统计冲突数量，大于 0 就记录一条冲突信息。为什么用count而不是查列表？因为排课过程中这个方法会被高频调用，count只返回一个数字，比返回整个结果集再判断长度要省内存和网络开销。

参数说明：teacherId、classroomId、classId是外键，分别指向教师、教室、班级表；dayOfWeek是星期几（一般用 1-7 的整数）；timeSlot是第几节课（比如 1-5 表示上午五节）。这三个字段组合起来唯一确定一个"时间格子"。注意dayOfWeek和timeSlot的类型要和数据库里保持一致，如果数据库存的是字符串"周一"，代码里传整数 1，查询永远返回 0，冲突检测就形同虚设——这是很隐蔽的坑。

3.3 课表生成：贪心 + 回溯的工程折中

真正生成整张课表时，源码里一般不会用纯回溯（数据量大时跑不动），而是"贪心为主、回溯兜底"。贪心的思路是：把课程按约束最紧的优先排（比如教师时间最少的先排），每排一门就调用上面的冲突检测，没冲突就落位，有冲突就换下一个时间段。如果所有时间段都冲突，再触发回溯，把前面某门课挪一挪腾位置。

// 简化的贪心排课主流程 public void generateSchedule(List<Course> courses) { // 按教师可用时间升序，约束紧的先排 courses.sort(Comparator.comparingInt(c -> c.getAvailableSlots().size())); for (Course course : courses) { boolean placed = false; for (TimeSlot slot : course.getAvailableSlots()) { Schedule temp = buildSchedule(course, slot); if (checkConflict(temp).isEmpty()) { scheduleMapper.insert(temp); placed = true; break; } } if (!placed) { // 记录排不下的课程，交给人工或回溯处理 unplacedCourses.add(course); } } }

逻辑说明：排序是贪心策略的关键，约束紧的课程可选时间段少，先排它们能减少后面"无位可排"的概率。buildSchedule负责把课程和时间段组装成一条待插入的记录。排不下的课程不直接丢弃，而是收集到unplacedCourses里，前端可以提示教务老师手动处理。

参数说明：availableSlots是每门课允许的时间段集合，这个集合怎么来，取决于你的业务规则——可以是教师填的可用时间，也可以是系统按班级课表算出来的空档。这个集合越小，排课越难，所以实际项目里通常会给教师一个"可用时间填报"页面，而不是让算法硬猜。如果你的数据里availableSlots是空的，排课会直接全部失败，先检查数据初始化脚本有没有把这块数据灌进去。

4. 避坑与排查：跑不起来、排不出课、结果不对怎么办

4.1 启动报数据库连接失败

现象：控制台抛Communications link failure或Access denied for user。原因通常是三种：MySQL 服务没启动、用户名密码错、或者url里的库名和实际建的不一致。解决：先在命令行用mysql -u root -p手动登录一次，确认服务活着、密码对；再核对application.yml里的库名拼写。如果是 MySQL 8.0，驱动类要写com.mysql.cj.jdbc.Driver，老版本的com.mysql.jdbc.Driver会警告甚至报错。

4.2 页面能打开但查不到任何数据

现象：首页正常，课程列表空白。原因多半是数据库表建了但没数据，或者 MyBatis 的type-aliases-package路径和实体类包名对不上，导致映射失败但被吞掉了异常。解决：先用SELECT COUNT(*) FROM course;确认表里有数据；再看启动日志有没有Invalid bound statement或Cannot find class的警告。实体类包名要和配置里写的一模一样，大小写都不能差。

4.3 排课结果出现教师时间冲突

现象：生成的课表里，同一个老师在同一时间段出现在两个教室。原因通常是冲突检测的查询条件漏了字段，比如只查了dayOfWeek没查timeSlot，或者timeSlot的类型在 Java 和数据库之间不一致导致条件失效。解决：把冲突检测的 SQL 单独拿到数据库里跑一遍，手动构造一条已知冲突的数据，看count返回是不是大于 0。如果返回 0，就是条件写错了。

4.4 排课跑很久甚至卡死

现象：点"生成课表"后页面一直转圈。原因：课程数量大时，贪心加回溯的复杂度会飙升，尤其是availableSlots集合很大、冲突又密集的情况。解决：给排课加一个最大尝试次数上限，超过就停止并返回已排部分；或者把排课改成异步任务，前端轮询进度。别让一个 HTTP 请求同步等几分钟，浏览器和网关都可能超时。

4.5 中文乱码

现象：课程名、教师名显示成问号或乱码。原因：数据库字符集、连接串字符集、页面编码三者不一致。解决：数据库建库用utf8mb4，连接串加useUnicode=true&characterEncoding=utf8，前端页面<meta charset="UTF-8">。三处统一，乱码基本就没了。

5. 二次开发与验证：怎么加一个约束、怎么确认改对了

拿到源码只是起点，真正体现水平的是你能不能按需求改。假设答辩时要加一条约束："同一个班级的课程尽量不连续排超过两节"，这就是一条软约束，不该塞进checkConflict里当硬约束拦，而应该在贪心选时间段时加一个评分：如果当前时间段和上一节是连续的，且已经连续两节，就降低这个时间段的优先级。

// 软约束评分：连续节次越多，分数越低 private int scoreSlot(Schedule candidate, List<Schedule> existing) { int consecutive = 0; for (Schedule s : existing) { if (s.getClassId().equals(candidate.getClassId()) && s.getDayOfWeek().equals(candidate.getDayOfWeek()) && Math.abs(s.getTimeSlot() - candidate.getTimeSlot()) == 1) { consecutive++; } } // 连续超过 2 节开始扣分，扣分值可调 return consecutive > 2 ? -(consecutive - 2) * 10 : 0; }

逻辑说明：这个方法遍历已有课表，统计和候选时间段相邻的节次数量，超过 2 就按超出数量扣分。排课时把候选时间段按"冲突检测通过 + 评分高"排序，优先选评分高的。参数说明：-(consecutive - 2) * 10里的10是权重，调大它，算法会更强烈地避免连堂；调小则更看重其他因素。这个权重没有标准答案，要拿真实数据跑几轮，看课表分布是否符合预期。

验证改动是否生效，别只看页面"看起来对了"。我的习惯是写一个简单的校验方法，把生成的课表全量扫一遍，统计硬约束违反次数，必须为 0；再统计软约束的分布，比如连堂超过两节的班级数量，改之前和改之后对比。数据不会骗人，肉眼扫课表一定会漏。

从那以后我每次改排课逻辑，都强制先跑一遍全量校验再交付，因为排课这种业务，一处小改动可能让整张课表悄悄崩掉，而页面上一眼看不出。希望这份拆解能帮你把这份源码真正用起来，而不是停在"能跑就行"。

本文还有配套的精品资源，点击获取