搞高校课表管理系统的时候，很多人一开始觉得“不就是把 Excel 搬到网页上吗”，真做起来才发现坑一个接一个：校级课表、班级课表、教师课表要同时查询，周次单双周要解析，调完课还要防冲突，并发一点、数据一乱，整个排课就翻车。我前一阵帮一所工商类高校做了这套课表管理系统，技术栈就是标题里那套经典的组合：SpringBoot + Vue + MyBatis + MySQL。整套系统的源码结构很清晰，既适合当课程设计和毕业设计参考，也可以直接压成一个小型校区的生产级项目。这篇文章就把项目的业务边界、表结构设计、后端接口逻辑、前端渲染过程以及实测中的问题和优化方案完整复盘一遍。
先说清楚，这篇不是那种泛泛讲“如何快速搭建增删改查”的入门教程，而是把课表系统里真正麻烦的那几件事掰开揉碎了讲。如果你接下来要做类似的教学管理系统、排课系统、考试安排系统，或者正在为毕设选题发愁，这篇文章会非常有用。
1. 这个课表系统的真实选题理由和业务范围
1.1 业务痛点：为什么不能继续用 Excel 排课
高校课表管理的痛点，有学校工作经历的应该都很熟悉。教务老师手里常年有好几份 Excel 表，一份按班级排，一份按老师排，还有一份按教室排。平时查课表、调课全靠表格里多次筛选，数据一多、学期一换，非常容易出错。
我这次做的这个系统，定位不是“自动排课算法”，而是先解决“排完之后的存储、查询、调整、冲突校验”这几个难题。一句话概括：老师可以登录查看自己的授课安排，学生可以查看班级每天的课程列表，教务管理员负责录入课程、分配教师和教室，遇到临时调课也能在系统里发起申请并立刻做冲突检测。
如果上了自动排课算法，比如遗传算法排课、贪心填教室，项目的复杂度会上一个量级。对大多数普普通通的课表管理系统来说，学校最迫切的需求是把现有的排课结果管理起来，而不是从零生成一张完美的课表。所以我一开始就把“自动生成课表”这个模块划掉了，第二期再做也不迟。
1.2 功能清单：哪些必须做，哪些先不做
我在第一版明确了范围，避免把项目膨胀到做不完。核心功能划分成三端：
- 学生端：登录后查看班级周课表，支持切换周次，能看到单双周课程。
- 教师端：查看个人课表，申请调课，查看调课审批结果。
- 管理员端：维护班级、教师、教室、课程等基础信息，录入排课记录，审批调课申请，处理冲突校验。
刻意没有做的部分包括：选课系统、成绩关联、考勤打卡、消息推送。原因很简单，这些功能会让权限模型复杂很多，也会拖慢核心模块的进度。做项目最忌讳的就是什么都想加，最后主流程都立不住。
我建议你拿到任何“课表管理系统”或者“排课系统”的课题时，也先做这一步动作：把需求收敛成一个可以闭环的核心流程。对于课表系统来说，闭环就是“录入课表 -> 存储设计 -> 查询展示 -> 调课冲突 -> 审批生效”。
2. 技术选型分析：SpringBoot + Vue + MyBatis + MySQL 这套组合为什么顺
2.1 后端框架选 Spring Boot 的理由
后端选 Spring Boot 可以说没有悬念。原因是它对约定优于配置贯彻得比较彻底，一个启动类就能把内嵌 Tomcat、自动配置、组件扫描全搞定。课表系统这类后台管理项目，业务逻辑相对规整，用它保存了很多繁琐的装配工作，开发起来非常快。
而且从找工作角度来说，Spring Boot 是目前国内 Java 开发者使用率最高的框架之一，作为项目展示放在简历上，对标岗位的匹配度也比小众框架高。配合 Spring MVC 的 Controller-Service-Mapper 三层模型，代码结构清晰，大家审阅源码也容易看懂。
2.2 为什么用 MyBatis 而不是 JPA 或者 MyBatis-Plus
这里有个经常被问的问题：“既然写管理系统，为什么不用 MyBatis-Plus？它的 BaseMapper 不是写着更快吗？”
MyBatis-Plus 的确很快，但我最终选的是原生 MyBatis，原因很实在：课表查询的场景有大量多表关联和动态条件，比如查询某个教室在第几周是否空闲、查询某个老师在某时间段是否有课，这类 SQL 往往不是简单的单表 CRUD 能解决的。原生 MyBatis 可以把 SQL 完全掌控在手里，在 XML 里写动态 SQL 非常直观，可读性和可优化性都很高。
如果用 JPA 或者 MyBatis-Plus，反而要在代码里拼接 QueryWrapper、Specification 这类对象，SQL 执行计划看不清楚，遇到复杂连接查询的时候不好调优。一句话总结：框架少做的，恰恰是我需要精雕细琢的那部分。
2.3 前端用 Vue 而不是 React 的原因
前端选 Vue，最大的原因就是上手门槛低、中文资源多，而且单文件组件写起来非常符合直觉。课表系统本身是一个相对封闭的中后台系统，不需要 React 那样庞大的生态体系，Vue 配合 Vue Router、Axios 完全足够。
我这次用的是 Vue 2 项目风格，因为项目里很多现成组件和案例还是 Vue 2 的语法，改成 Vue 3 组合式 API 会让阅读成本略微增加。如果你是自己新起项目，建议直接上 Vue 3，但整体业务逻辑是完全一致的。页面上主要使用了表格布局、下拉选择框、对话框，这些在 Vue 生态里都是非常成熟的操作。
2.4 整体项目结构
项目分前后端两个目录，后端是标准的 Maven 多模块或者单模块结构，前端是 Vue 工程。为了方便大家阅读源码，我的目录组织是这样的：
后端： ├── src/main/java/com/xx/edu/ │ ├── controller/ # 控制层，接收参数和返回结果 │ ├── service/ # 业务逻辑层，处理周次解析和冲突检测 │ ├── mapper/ # MyBatis Mapper 接口 │ ├── entity/ # 数据表实体类 │ ├── common/ # 统一返回结果、异常处理、工具类 │ └── config/ # 跨域、拦截器等配置 前端： ├── src/ │ ├── api/ # axios 接口封装 │ ├── router/ # 路由配置 │ ├── views/ # 页面：登录/班级课表/教师课表/管理后台 │ ├── components/ # 可复用组件：周次选择器、课表格子 │ └── store/ # 登录信息和当前用户状态这个结构看起来简单，但足够支撑一个中小型管理系统的开发。重要的是，每一个层做的事情都很明确。
3. 数据建模：课表系统的表结构与冲突约束
3.1 核心表之间的关系
数据库设计是整个系统的地基，也是最容易做错的地方。课表管理核心涉及这几类实体：用户、班级、教师、教室、课程、排课记录。
用户表（sys_user）保存账号、密码、姓名、角色类型，角色可以区分学生、教师、管理员。这里不把学生和教师拆成两张表，是为了减少权限校验的复杂度，用一个 role 字段区分即可。班级表（class_info）保存班级名称、所属专业、年级。教师表（teacher_info）保存教师工号、姓名、职称、所属院系。教室表（classroom）保存教室编号、校区、容量、类型，比如普通教室还是多媒体教室。
排课表（timetable）是核心中的核心，它把班级、教师、教室、课程、周次、时间片都关联起来。一条 timetable 记录就代表“某课程在某一周的某个时间片，安排在某个教室，由某位老师教授”。
实际还会有一个调课申请表（course_adjust），记录申请老师、原时间、新时间、申请理由、审批状态。每次调课会先写申请记录，再在后台做冲突校验，通过之后由管理员确认，最后才真正更新 timetable。
3.2 周次和时间片的设计
周次处理是课表系统里最阴间的部分。高校课表不是每天都一样的，普遍存在单双周概念，比如“第1-16周单周上课”，还有“第1-8周、第10-16周分段上课”。如果直接用两个字段 start_week 和 end_week 存一个区间，遇到分段周次就得存多条记录，或者存一个复杂字符串。
我采用的思路是：用 week 字段存储一个逗号分隔的字符串，比如 "1-16" 表示连续16周，"1,3,5,7,9" 表示单周，"1-8,10-16" 表示两个连续区间的并集。在查询时，后端写一个工具类把字符串解析成集合，判断目标周次是否属于该集合。这样存储非常灵活，存储成本也可以忽略不计。
时间片的表示也要小心。常见高校一天的课程分为上午、下午、晚上三个时段，每个时段有若干节次，节次组合又分为单节、两节连上、三节连上。不能简单存一个“第几节”，因为课程往往从第1节上到第2节。我使用 start_section 和 end_section 两个字段，再加一个 day_of_week 字段表示星期几。例如周五下午第7-8节，存为 day_of_week=5, start_section=7, end_section=8。
3.3 冲突检测的核心：联合唯一索引和业务校验
课表系统最怕的就是教室不够、老师分身乏术或者班级被排重。要避免这些问题，除了代码里做判断，数据库层面也需要一把“锁”。我在 timetable 表上设计了联合唯一索引，原则是“同一资源在同一时间只能被使用一次”。
不同维度有不同资源：
- 同一教室：UNIQUE KEY uk_classroom_time (classroom_id, day_of_week, start_section, week)
- 同一教师：UNIQUE KEY uk_teacher_time (teacher_id, day_of_week, start_section, week)
- 同一班级：UNIQUE KEY uk_class_time (class_id, day_of_week, start_section, week)
这里必然有人问：week 是字符串，关联唯一索引时只要这个字符串不完全相同就不会命中索引，那么冲突检测怎么生效？
这个问题问到点子上了。所以上面索引里的 week 字段，不能存原始字符串。我在业务表里额外加了一个 week_bitmap 字段，用二进制或者整型掩码来表示具体哪些周有效。比如一个 int 类型字段的每一位代表一个周次，第1周有效就把第1位置1。这样每周生成的索引记录就是固定的离散值，真正能用到唯一索引去挡冲突。
当然，直接用 int 掩码在业务上不直观，所以对外仍然展示 week 字符串，内部写入时才转换成掩码存到唯一索引字段。数据库唯一索引的作用是最后一道物理防线，业务代码里的逻辑校验才是用户体验的保证。
4. 后端核心逻辑：排课、查询、调课的接口实现
4.1 接口设计与请求样例
后端接口遵循 RESTful 风格，核心接口有这些：
| 接口 | 方法 | 说明 |
|---|---|---|
| /api/user/login | POST | 登录并返回 Token |
| /api/timetable/class/{classId} | GET | 获取指定班级课表 |
| /api/timetable/teacher/{teacherId} | GET | 获取指定教师课表 |
| /api/timetable/classroom/{roomId} | GET | 获取指定教室课表 |
| /api/timetable/add | POST | 添加排课记录 |
| /api/adjust/apply | POST | 发起调课申请 |
| /api/adjust/approve | PUT | 审批调课申请 |
| /api/base/class | GET | 获取班级列表 |
| /api/base/classroom | GET | 获取教室列表 |
| /api/base/teacher | GET | 获取教师列表 |
查询课表时，前端会传学年学期参数、角色对应 ID 和具体的周次。例如请求/api/timetable/class/1001?week=5&semester=2024-2025-1，后端将周次解析成校验数据，然后返回该班级在第5周的全部课程记录。
4.2 周次解析工具的实现
周次解析这部分代码虽然短，但特别值得单独讲。假设 week 字段存的是 "1-8,10-16"，工具类需要把它解析成一个 boolean 数组或者 Set ，方便第 10 周、第 11 周、第 12 周这些判断一次性完成。
核心思路是：先按逗号拆段，每一段再判断是单个数字还是区间。如果是 "1-8"，就循环从 1 到 8 加入集合；如果是 "3,5,7"，则直接加数字。解析完成后，判断某个周是否在该集合就是 O(1) 的操作。
这类工具最好放在 common 包里，并且写单元测试覆盖边界条件，比如 "1-1"、空字符串、非法输入。别小看这段代码，出 bug 的频率往往就集中在字符串拆分的边界情况上。
4.3 MyBatis 动态 SQL 的踩坑笔记
课表查询通常会涉及多表连接。以班级课表查询为例，前端传来的条件有时间片范围、教室类型、教师姓名等，这些条件有些存在，有些不存在，用 MyBatis 动态 SQL 处理是最合适的。
一个典型的 Mapper XML 片段：
<select id="selectClassTimetable" resultType="com.xx.edu.entity.TimetableVO"> SELECT t.id, t.day_of_week, t.start_section, t.end_section, c.course_name, c.course_type, tc.teacher_name, cr.room_name, t.week, t.week_bitmap FROM timetable t LEFT JOIN course_info c ON t.course_id = c.id LEFT JOIN teacher_info tc ON t.teacher_id = tc.id LEFT JOIN classroom cr ON t.classroom_id = cr.id <where> <if test="classId != null"> AND t.class_id = #{classId} </if> <if test="teacherId != null"> AND t.teacher_id = #{teacherId} </if> <if test="dayOfWeek != null"> AND t.day_of_week = #{dayOfWeek} </if> <if test="startSection != null"> AND t.start_section >= #{startSection} </if> <if test="endSection != null"> AND t.end_section <= #{endSection} </if> </where> ORDER BY t.day_of_week, t.start_section </select>这里有两个坑必须提醒大家。第一个坑是 XML 里的小于号、大于号必须转义，比如>=写成>=，否则 XML 解析直接报错。第二个坑是使用<where>标签后，如果所有条件都不加，它不会拼出多余的 WHERE，但如果第一个条件成立，后续条件都要手动写 AND，不要漏掉。
MyBatis 的动态 SQL 功能本身不复杂，但新人在排查问题时常常盯着代码看半天发现是空格或者符号问题。我建议把查询语句用日志完整输出出来，比如在 application.yml 里配置：
mybatis: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl这样每次执行 SQL 都能看到完整语句，排查动态 SQL 真的很舒服。
4.4 调课冲突检测：数据库唯一索引之外的业务校验
调课的场景是这样的：老师甲周三上午第1-2节原本有课，临时想调到周四下午第7-8节。管理员在系统里填入新的时间片、教室，后端要判断周四下午这个时间“班级是否空闲”“教室是否空闲”“老师是否空闲”。
我实现冲突检测的逻辑是：
- 根据原始 timetable 记录找到关联的班级 ID、老师 ID、教室 ID。
- 构造新的 week 字符串解析结果，转成新的 week_bitmap 集合。
- 查询新增时间范围内，是否存在其他 timetable 记录落在同一目标集合里。
- 如果有冲突，则不通过；如果没有，则进入审批记录，管理员确认后执行 UPDATE。
数据库唯一索引在这里的作用是兜底。即便并发导致两条请求同时进入，最终也只有一条能插入成功，另一条会抛出 DuplicateKeyException。业务代码捕获这个异常并提示“该时间段存在冲突”，这样用户感知上也是合理的。
不过要注意，唯一索引冲突抛出的异常在事务里会导致整个事务回滚，如果要对外包一层提示，建议把插入操作放在独立事务中，或者捕获异常后重新抛出业务异常。我之前在这个点上卡过几小时，后来把冲突检测和写入操作拆成两个明确的方法才理顺。
5. 前端渲染流程：从当前周次到单元格课表
5.1 整体组件拆解
前端核心页面就是课表主页。我把页面拆成了三个组件：WeekSelector（周次选择器）、TimetableGrid（课表主体）、CourseCell（课程单元格）。
WeekSelector 负责显示当前校历的第几周，提供上一周/下一周的切换按钮，同时支持直接输入数字跳到指定周次。TimetableGrid 根据后端返回的课程数据，按星期一到星期日纵向排列，横向按节次分组，形成一个标准的课表网格。
CourseCell 是单个格子，显示课程名称、授课教师和教室。点击单元格后会弹出课程详情，附近的同类课程在多个课程下可以弹出选择列表。这种做法比把所有信息塞进一个格子清爽得多。
5.2 周次变化的数据刷新
课表页的核心交互逻辑是“切换周次 -> 重新加载数据”。这里要注意，不要一刷新就把整张表重新请求一遍，也不要把所有周的数据一次性全拉下来。实际课程数据总量不算太大，一次性全拉下来会出现加载缓慢和数据结构混乱两个问题。
我的做法是每次切换周次时，触发一个请求函数，携带当前选中的周次和班级 ID 请求后端接口，拿到数据后更新当前周次的课程列表。在 Vue 中，这通常是一个 watch 函数，监听 currentWeek 的变化，变化后调用 fetchTimetable()：
watch(currentWeek, (newWeek) => { fetchTimetable(newWeek) })与此同时，为了提升体验，页面加了 Loading 状态和错误提示。网络情况差的时候，用户能看到加载中的遮罩，不会误以为系统坏了。
5.3 单元格渲染与冲突高亮
课程渲染最核心的部分是把后端返回的day_of_week、start_section、end_section映射到正确的位置。我实现了一个二维索引结构，比如const cellMap = {}，把day + '-' + section作为 key，课程数据作为 value。遍历返回数组，将每一条课程放进对应的 key 下，然后在界面渲染时依次检查每个格子。
冲突高亮是课表系统一个很贴心的功能。正常来说，后端已做了冲突检测，前端很少会遇到真实冲突。但在调课预览或管理员手工录入时，前端可以先展示候选时间是否与现有课表重叠，用醒目的红色或黄色背景提示。
我在前端做了一个 locally 检查：当用户在当前页面模拟添加课程时，对已有 cellMap 做一次遍历，如果发现相同 day、相同 section 区间已经存在课程，将新课程背景置为红色并弹窗提示。这样即使后端接口没有来得及返回错误，用户也能第一时间感知问题。这等于是把“所见即所得”的用户体验往前端推了一把。
6. 联调、并发测试和实际运行中的问题
6.1 并发场景下踩到的重复提交问题
课表管理系统看起来并发量不高，但到了选课高峰或者集中排课的时候，多位教务管理员可能同时操作，这时候重复提交就非常明显。最经典的案例是：管理员快速双击“保存排课”按钮，前端发出两次请求，后端如果没有做幂等处理，就会进入两个事务，两个事务又同时去查询空闲教室，查询结果都显示空闲，最终插入两条记录。
我的解决方案是在插入接口上加一个“请求唯一编号”。前端每次打开弹窗时生成一个 UUID，作为参数带到后端，后端在插入 timetable 之前检查这个 UUID 是否已经存在。如果已经存在，直接返回“重复提交，请勿重复操作”。这个方法比单纯禁用按钮可靠很多，因为按钮禁用只在单个浏览器内有效，不能防止多端同时提交。
另外，并发插入时数据库唯一索引的异常也要单独处理。我写了一个统一的异常处理器，捕获 DuplicateKeyException，并转换为友好的业务提示：
@ExceptionHandler(DuplicateKeyException.class) public R<Void> handleDuplicateKey(DuplicateKeyException e) { return R.fail("该时间段存在冲突，请检查教师、教室或班级是否空闲"); }6.2 慢查询和索引优化
一期上线后，最影响体验的查询是“查询某教室在全校的空闲时间列表”。这个查询需要把教室表、timetable 表、课程表三张表做连接，在数据量有几万条的时候已经能感觉到明显卡顿。
我用 EXPLAIN 看了一下执行计划，发现确实走了全表扫描。优化方式是给 timetable 的 classroom_id、day_of_week、start_section 三个字段加上组合索引，单独查询教室的时候可以快速定位到目标记录。同时，查询“空闲教室”时，要先把该教室所有已占用时间一次性取出来，再在内存里做时间段比较，而不是对每一节课单独发起查询。
内存里做时间比较也有技巧。已占用的时间段可以按开始节次排序，把每个已占用区间拉成一个数组，之后判断目标时间片是否落在任何占用区间内，使用数组二分查找或者按顺序线性扫描，效率都很高。这个做法比我之前用嵌套循环逐个判断要快不少。
6.3 部署和运维的小细节
项目部署用的是 CentOS 服务器加 Nginx。后端打包成 jar 包，用 systemd 守护运行，前端 build 之后把 dist 目录交给 Nginx 托管，同时配置反向代理，将/api路径转发到后端的 8080 端口。
固定这套部署方式时，要注意跨域问题。开发阶段我开启了后端跨域配置，但生产环境建议关闭跨域，统一走 Nginx 代理，安全性和稳定性都会更好。否则前端到后端的请求会出现 CORS 错误，浪费不少排查时间。
另外，数据库每天建议做一次自动备份。高校课表数据的重要性超出想象，一旦误删或者覆盖，恢复成本极高。我用一个简单的 crontab 定时任务把 MySQL 数据库导出到备份文件，保留最近30天。备份策略虽然基础，却能在事故发生时救你一次。
7. 学习价值与下一步扩展建议
7.1 这套代码最值得写进简历的核心亮点
如果这个项目用于毕业设计或者求职项目，有几个点值得在面试中重点强调：
- 周次解析和 week_bitmap 的设计，说明了你不是单纯做 CRUD，而是理解了排课场景的领域复杂性。
- 冲突检测的双重保障，既在业务层做了逻辑校验，又在数据库层建了唯一索引，体现了“纵深防御”的思维。
- MyBatis 动态 SQL 的应用，说明你能根据复杂查询条件编写可维护的 SQL。
面试官通常不太在意页面漂不漂亮，而是关心“你的系统如何防止老师同时出现在两个教室”，“课程单双周是怎么实现的”。这两个问题回答好了，就会留下明显的好印象。
7.2 从课表系统扩展到教务系统
课表系统做完之后，很自然地会往外扩展。首先可以增加自动排课算法，把老师、班级、教室和时间片用约束满足的方式自动分配，这是算法方向的重要延伸。其次可以引入学期节次配置、节假日管理，当法定节假日调休时，课表周次能自动关联校历，这个功能对实际使用非常友好。
还可以加导出课表的功能。实际场景中，老师还是很想要一张 PDF 版课表贴在办公室的。项目里可以集成导出组件，把前端表格转成 PDF 或 Excel。这个需求不大，但在真实使用中能很明显提升满意度。
如果还有余力，可以做基于角色的数据权限，让不同学院的教务员只能管理本学院的课程和班级，而不是所有人都能改全校数据。权限模型升级之后，系统的适用面会宽很多，也能应对更复杂的组织结构。
7.3 我最后想强调的一点经验
进学校类的管理系统开发，最容易被忽略的就是“校历”“单双周”这类的领域细节。很多代码跑起来很顺，一遇到真实排课数据的各种奇怪编排就会彻底崩掉。做这套系统的时候，我反复提醒自己：先花一半的精力去理解业务规则，再去想技术方案。
如果你打算照着标题里的那套源码或者自己搭建类似项目，建议把最初的排版对齐和数据验证做好，再去想各种高级优化。稳定和可用，永远比炫技重要。课表系统的复杂度摆在那，但只要你把表结构和冲突检测的思路打通，整个项目就立住了一大半。
