基于SpringBoot2+Vue3的课表管理系统：从数据库设计到部署排障

课表管理系统这题我太熟了，大学校园里天天见的东西，但真把它做成一个完整的、可落地的前后端分离项目，还是有不少门道的。最近刚好梳理了一个基于SpringBoot2 + Vue3 + MyBatis-Plus + MySQL8.0的西安工商学院课表管理系统源码，带完整文档，正好把里面的技术细节、设计思路和踩坑记录整理出来。这篇文章会从需求拆解、数据库设计、后端通用CRUD、课表冲突检测、前端课表渲染、部署排障这几个维度展开，适合正在做毕设、JavaWeb项目练手，或者想完整走一遍前后端分离开发流程的同学参考。

1. 项目整体设计与思路拆解

1.1 需求解读：课表系统到底要解决什么问题

很多同学一听到“课表管理系统”就觉得简单——不就是把课程、时间、教室三个东西塞进一张表里吗？真上手做才发现，排课这个业务逻辑比想象中要拧巴。课表系统的核心痛点在于“时间维度的冲突检测”和“多维度的查询渲染”。

一个教学班需要排入一个固定的教室、固定的星期节次、固定的起止周次，还要考虑同一教师不能在同一时间出现在两间教室，同一教室不能被两个教学班同时占用。这种业务约束如果只靠前端的表单校验，根本挡不住漏洞，必须把约束下沉到后端和数据库层面。

西安工商学院这种规模的校园，日常课表数据量大概在上千条，排课记录可能到几千条。虽然数据量不大，但查询场景非常杂——学生要看自己的课程表，教师要看授课安排，教务管理员要做冲突检测和调课。这些查询都需要按班级、按教师、按教室、按周次做维度组合，这就要求后端接口在设计上必须足够灵活，不能写死SQL。

另外还要考虑的是课表的可视化呈现。用户不想要一张干巴巴的列表，而是希望看到像教务系统那样横七竖八的表格：横向是星期一到星期五（或者星期六），纵向是第几节到第几节，单元格里是课程名、教室和授课教师。这种交互难度的重点不在数据，而在前端怎么把数据结构映射成表格布局。

1.2 技术选型对比：为什么是SpringBoot2 + Vue3 + MP + MySQL8.0

这套技术栈在2025年看来不算新潮，但胜在稳定、生态成熟、资料量大、社区排障成本低。SpringBoot2目前依然是大量高校和企业项目的基石版本，SpringBoot3的Jakarta命名空间和GraalVM支持虽好，但对于课表这种业务系统，升级收益不大，反而会带来一些老依赖兼容的麻烦。如果是做毕设或中小型项目，SpringBoot2完全够用，而且招聘市场上对SpringBoot2/3的认知是等价的，面试官更看重你能不能把底层逻辑讲清楚。

Vue3在经历了几年沉淀后，已经成了前端的主流选择，Composition API加<script setup>的写法配合Element Plus，开发体验比Vue2时代的Options API舒服很多。这个项目选的Vue3，核心原因在于组件复用和状态管理——课表组件、课程弹窗、周次切换器这类交互模块，用组合式函数抽离业务逻辑后，代码可维护性明显提升。

MyBatis-Plus不需要多说，它在MyBatis之上的增强属于提升开发效率的那一挂。课表系统很多接口是纯粹的CRUD，用MP的BaseMapper和IService能少写大量样板代码。再加上分页插件、逻辑删除、乐观锁这些内置能力，对于中小系统开发来说省下的时间非常可观。

MySQL8.0相比5.7的改进集中在窗口函数、JSON支持、性能优化和默认字符集utf8mb4上。课表系统里按周次展开、跨周查询这类逻辑，窗口函数可以写出更优雅的SQL。另外8.0的WITH语法（公用表表达式）在复杂的课表聚合查询里也好用。既然新装环境，没有必要再去选老版本。

1.3 系统模块划分与数据流

整个系统按角色可以拆成三个端：管理员端、教师端、学生端。三端在功能上有重叠，但权限差异明显。管理员负责基础数据维护——班级、教师、教室、课程、排课计划的管理；教师可以查看自己的授课表并提出调课申请；学生只能查看本班课表和空教室查询。这种角色设计的背后是一个经典原则：权限最小化，数据范围隔离。

模块划分上，后端拆出了用户认证模块、基础信息管理模块、排课管理模块、课表查询模块、调课审批模块。前端按照页面维度拆成了系统管理、课程管理、排课管理、课表视图、个人中心。数据流大概是这样的：管理员维护班级教师课程等基础数据后，在排课模块完成排课，排课数据落库，学生或教师端通过查询接口拿到渲染数据，前端格化为可视化课表。

这种架构在数据流上有一个关键点：查询课表时不要一次性把全部排课记录查出来，而是先确定查询维度（班级ID、教师ID还是教室ID），再带着周次参数去过滤。这个思路会在后面的接口设计里详细展开。

2. 后端核心实现：SpringBoot2 + MyBatis-Plus实战

2.1 数据库设计与表结构

课表系统的数据库设计是整个项目最见功力的地方。我见过很多项目一上来就搞一张大宽表，把所有信息都塞进排课表里，这种做法在维护时非常痛苦。标准的设计应该遵循“基础数据与业务数据分离”的原则。

基础表包括：sys_user（用户表）、sys_role（角色表）、student（学生表）、teacher（教师表）、class_info（班级表）、course（课程表）、classroom（教室表）。业务表主要是course_schedule（排课表）和schedule_adjust（调课申请表）。

先看基础表的设计要点。学生表和教师表为什么不直接复用用户表？因为用户表只管登录认证，而学生有学号、班级归属，教师有工号、职称、所属院系，这些业务属性如果堆在用户表里，会导致大量字段冗余。合理做法是用户表存账号密码角色，学生表或教师表通过user_id关联用户表。

课程表字段要包含课程名称、课程代码、学分、总学时、周学时、课程性质（必修/选修）。这里有个细节：课程学时和周学时如果不在表里冗余，排课的时候就无法校验“排课节次是否超出课程总学时”，所以这两个字段必须提前存好。

教室表除了教室名称和位置，还要存容纳人数和教室类型（普通教室、多媒体教室、实验室）。排课冲突检测时，教室容量也是校验条件之一：如果一个班有60人，就不能排进50人的小教室。

排课表course_schedule是这个系统最核心的表，字段设计要特别小心：

这里有几个值得展开的设计决策。第一，周次为什么用week_start和week_end加week_type三元组，而不是直接存所有周次序列？因为一个排课计划通常是一个连续的周段，比如第1周到第16周，偶尔有单双周的区分。用三个字段可以覆盖绝大多数场景，也方便写冲突检测SQL。如果存逗号分隔的第1,3,5,7周，查询性能很差且SQL很难写。

第二，节次为什么用start_section和end_section？一天有12节课，分为上午、下午、晚上，一个教学安排可能占用两节甚至三节连排。用起止节次比存单个节次更灵活，冲突检测时判断两个排课记录是否时间重叠，核心逻辑就是比较两组起止节次是否有交集。

排课表的索引设计也不能漏。我在这张表上建了联合索引(class_id, day_of_week, start_section)、(teacher_id, day_of_week, start_section)、(classroom_id, day_of_week, start_section)。原因很直接：学生查课表时，查询条件是班级加周次；教师查课表是教师加工星期。这些联合索引能让常见的查询走索引，避免全表扫描。实测数据量几千条时全表扫描也没多大问题，但设计索引本身就是一种职业习惯。

2.2 通用CRUD服务的实现思路

SpringBoot2 + MyBatis-Plus的组合下，通用CRUD服务写起来非常顺手。MyBatis-Plus的核心价值在于：不需要写XML或注解SQL，只要继承BaseMapper和IService接口，就能获得单表的增删改查能力。课表系统里班级管理、课程管理、教室管理这类模块，几乎不需要手写SQL。

以课程管理为例，实体类Course加上@TableName("course")注解，Mapper接口继承BaseMapper<Course>，Service接口继承IService<Course>，ServiceImpl继承ServiceImpl<CourseMapper, Course>。三行接口声明，基本的CRUD就有了。

但通用CRUD不意味着无脑用。课表系统里的几个核心查询都比较复杂，比如“按班级查询第几周的课表”，需要关联课程表、教室表、教师表，同时要过滤周次条件。这种场景下我会选择在Mapper里写自定义SQL，或者用MyBatis-Plus的LambdaQueryWrapper拼装动态查询条件。前者的好处是SQL可读性高、便于调优，后者的好处是不用写XML，动态条件拼装更灵活。

我实际编码时比较强调一点：不要在整个项目里混用两套风格。一个Mapper要么走自定义SQL，要么走Wrapper，混用会让维护的人精神分裂。课表系统里我把简单查询全部交给Wrapper，把带JOIN和复杂条件统计的查询全部放进XML里，边界非常清晰。

以排课记录查询为例，前端需要返回课程名称、班级名称、授课教师、教室位置，这些信息散落在四张表里。我设计一个ScheduleVO对象，在Mapper XML里写一条连表查询，然后分页返回。MyBatis-Plus的分页插件配置很简单，注入一个MybatisPlusInterceptor，添加PaginationInnerInterceptor即可。这里有个坑：分页插件的DbType一定要指定为MYSQL，否则方言识别可能出问题。

2.3 排课冲突检测的实现逻辑

排课系统的灵魂在于冲突检测。管理员排课时，系统必须在后端拦截以下几类冲突：

• 同一班级在同一时间被安排了两门课
• 同一教师在同一时间被安排在两个教室
• 同一教室在同一时间被两个班级占用

这三类冲突的检测逻辑本质上是同一个问题：给定了星期几、起止节次、起止周次，检查已有排课记录中是否有时间重叠的记录，且关联的班级/教师/教室相同。

时间重叠判断的SQL条件可以用一句话概括：day_of_week = 当前星期 AND start_section <= 新排课的结束节次 AND end_section >= 新排课的开始节次。这个条件能覆盖所有重叠情况，无论是部分重叠还是完全包含。

周次维度要复杂一些。两个排课记录即使星期节次完全相同，如果周次错开，比如一个是单周一个是双周，那也不冲突。所以在写冲突检测时，周次条件需要放在应用层判断，而不是单纯靠SQL。我的做法是先按星期和节次条件把候选记录查出来，然后在Java代码里二次判断周次是否有交集。

周次交集的判断逻辑用数学表达比较清晰：week_start <= 新的结束周 AND week_end >= 新的开始周，同时要考虑week_type的兼容性。我把这个逻辑写成一个工具方法，接收两个排课对象的周次参数，返回是否冲突。代码不长，但很关键，值得反复测试边界条件——比如一个记录是全周，另一个是单周，它们有交集吗？答案是有，因为单周落在全周范围内。

除了时间冲突，还有一个容易被忽略的容量冲突：教室容量是否足够。这个校验逻辑放在排课提交接口里，拿班级人数和教室容量做比较。班级人数在班级表里冗余，教室容量在教室表里，两个表一查就能判断。

冲突检测的返回信息要做友好化处理。不能只告诉管理员“排课失败”，要具体说明冲突类型——你是撞了班级、撞了教师还是撞了教室，以及具体撞上了哪条排课记录。我的实现方案是让冲突检测方法返回一个ConflictType枚举，前端拿到后展示对应的提示文案。这块细节直接决定系统好不好用，而且能体现一个开发者的细致程度。

2.4 接口设计与返回格式统一

后端接口设计的统一性直接影响前端开发的效率。我在这套系统里规定了一套响应体格式：code、message、data三个字段，成功时code为200，失败时code为错误码。这种格式和主流企业中台的做法一致，前端封装axios拦截器后，能统一处理错误弹窗和登录过期跳转。

课表查询接口的设计思路要重点说一下。前端课表视图需要一次拿到整个学期的完整课表，而不是一条一条地查。我设计的接口是GET /api/schedule/table?dimension=class&id=1&week=5，dimension参数支持class、teacher、classroom三种取数维度，返回的数据结构是一个二维数组嵌套结构：外层是星期几，内层是节次，每个格子是对应时间段的数据列表。

这种接口的好处是前端拿到的数据已经按展示结构组织好了，直接把数组交给表格组件就能渲染。坏处是后端要做数据组织，等于把一部分前端的活揽了过来。但权衡下来，对课表系统这种高频查询的场景，后端组织好数据结构的方案整体更优，能避免前端每次都要灰头土脸地循环整理。

返回的ScheduleCellVO每个格子包含：课程名称、授课教师、教室位置、起止节次、周次信息、排课ID。前端拿到以后，点击格子可以弹出课程详情，也可以触发调课申请。这里有个经验：格子里的课程如果是多节连排，应该合并单元格显示，前端组件要处理好合并逻辑。

3. 前端Vue3工程化实践

3.1 工程搭建与技术栈选型

前端选用Vue3后，脚手架我建议直接用Vite，而不是老牌的Vue CLI。Vite的冷启动速度和热更新体验比Webpack系的Vue CLI好了不少，尤其项目规模上来以后，这个体感差距非常明显。npm create vue@latest就能拉一个带路由和状态管理的模板，几分钟搞定。

项目里前端的完整依赖是：Vue3 + Vue Router + Pinia + Element Plus + Axios + Day.js。Vue3的组合式API配合<script setup>语法以后，代码结构清爽很多。举个例子，课表管理页面有大量的筛选条件——选择班级、选择周次、切换维度，这些筛选状态我用一个ref声明，再配一个响应式数据去接收课表结果，整个页面逻辑一目了然。

Pinia作为状态管理工具，在这套系统里的定位是存储用户登录态、角色信息、侧边栏折叠状态。课表系统的状态数据不复杂，没有必要把所有的接口数据都塞进Pinia，存全局通用的数据就够了。有些同学喜欢把后端返回的课表数据也放进Pinia缓存，我之前试过，后来放弃——因为课表数据实时性要求不高，但周次切换会频繁刷新，缓存反而会增加复杂度。缓存能做，但衡量投入产出比后，我认为直接请求更省心。

Element Plus是这套系统的主要UI组件来源。表格、表单、日期选择器、弹窗、消息提示、面包屑，这些常见组件都有，省去大量造轮子的时间。不过有一点要提醒：Element Plus的el-table虽然功能强大，但渲染课表视图时我不建议直接用它，原因是课表这种“复杂表头 + 合并单元格”的场景，用el-table反而要写一堆合并逻辑，不如直接用原生CSS Grid或普通表格来得灵活。这个我在课表渲染部分具体展开。

3.2 课表视图组件的核心实现

课表视图是整个前端项目技术含量最高的部分。界面要呈现的效果是：星期一到星期六作为6列，一天按节次分成12行，每个格子对应“星期X + 第Y节”。点击格子后弹出课程详情，支持调课操作入口。

我用CSS Grid来实现这个布局，这是当前最推荐的做法。先把容器定义成display: grid; grid-template-columns: repeat(6, 1fr); grid-template-rows: repeat(12, 60px);，再把每个排课格子通过grid-column和grid-row定位到对应的位置。多节连排的课程设置grid-row: span 2就能自然合并，不需要额外写合并逻辑。

为什么不用el-table？因为课表渲染本质上是一个“根据坐标放置内容”的棋盘模型，不是数据表格模型。CSS Grid的定位方式天然适配这种棋盘。而且合并单元格的问题，Grid通过grid-row: span解决得非常优雅——一个放置逻辑就给到了，而el-table需要先计算哪些行列合并。代码写起来就更简单了。

课表数据从后端拿到以后，组件的处理逻辑是：先把一维数组转换成坐标映射，用一个Map以day + '-' + startSection作为键，存对应的课程信息，渲染时每个格子自动查找Map里有没有东西。这样效率非常高，渲染12 × 6 = 72个单元格，每个格子做一次Map查询，时间复杂度是O(n)，性能没有任何压力。

周次切换是课表视图交互的另一大核心。学期一共有20周，用户点击上一周或下一周，课表内容要跟着变化。我的处理方式是：周次作为响应式数据，切换时重新调用后端接口，拿到当前周的数据再重新渲染。这种做法的前提是后端接口支持周次参数，这也是我在后端设计里反复强调周次过滤要放在服务端的原因。前端只负责传参和渲染，不负责过滤。

课程格子的样式要区分颜色，不同课程性质用不同底色——必修课蓝色、选修课绿色、体育课橙色。颜色映射可以用一个简单的函数判断课程类型后返回对应的CSS类名。还有一个小细节：格子里展示的文字信息要压缩，默认只显示课程名和教室号，完整的教师信息放到点击后的弹窗里。这样设计是因为格子空间有限，信息过载反而看不清。

3.3 与后端对接的技术细节

前后端联调最烦的就是接口路径和参数名不一致。我在项目里强推一个规范：接口路径统一/api前缀，后端Controller类上加@RequestMapping("/api/xxx")，前端axios实例的baseURL也指向/api，这样如果后端部署在localhost:8080，前端请求会直接转发到localhost:8080/api/...。

开发环境的跨域问题需要重点关注。前端开发服务器默认跑在5173端口（Vite），后端跑在8080端口，两者端口不同必然产生跨域。我的解决方案是前端Vite配置代理，把所有/api开头的请求代理到http://localhost:8080。这种方式的好处是生产环境部署时前端和后端都通过nginx代理，不需要改代码。

axios拦截器的封装也是对接环节必不可少的。请求拦截器里自动带上JWT Token，响应拦截器里统一处理后端返回的code：200直接返回data字段；401跳转登录页；其他错误码弹出全局消息提示。这套封装看起来简单，但能避免前端每个接口都要重复写错误处理的样板代码。

日期和周次的对应关系，也就是展示层面的“本学期第几周”的标题显示，我推荐用Day.js来处理。后端接口返回的数据里包含semesterStart字段，前端计算出当前日期距离开学日期差了多少天，除以7加1就是当前教学周。这样比让用户手动选周次更聪明，细节体验好很多。

4. 实操部署与踩坑记录

4.1 环境准备：MySQL8.0安装与Docker部署

MySQL8.0的安装是很多新手第一个崩溃的环节。Windows环境的同学可以下载安装包，一路Next就行，但要注意安装时选择UTF-8字符集，密码设置别太复杂。Linux环境的同学，我建议直接用Docker部署，省事得多。

Docker部署MySQL8.0的命令很简单：

docker run -d \ --name mysql8 \ -p 3306:3306 \ -e MYSQL_ROOT_PASSWORD=yourpassword \ -e MYSQL_DATABASE=schedule_db \ --restart=always \ mysql:8.0

这里有个关键参数--restart=always，能让容器在服务器重启或容器崩溃后自动拉起，生产环境部署时强烈建议加上。容器启动后，用docker exec -it mysql8 mysql -uroot -p进入MySQL命令行创建业务表即可。

MySQL8.0和旧版本有个重大区别：默认的认证插件是caching_sha2_password。如果你的后端项目用的是老版本的数据库驱动，连接数据库时会直接报错Unable to load authentication plugin。解决办法有两个：一是升级驱动到mysql-connector-java8.0以上版本；二是在MySQL里把认证插件改回mysql_native_password。我实际开发时两种方案都试过，升级驱动最省事，不改数据库端配置，也更安全。

另一个MySQL8.0的坑是时区问题。数据库连接串如果不指定时区，SpringBoot启动时会报错The server time zone value is unrecognized。正确做法是连接串里加serverTimezone=Asia/Shanghai参数。这个问题在很多教程里不会写，但新手几乎必踩。

4.2 项目运行步骤与配置详解

后端项目跑起来之前，要检查application.yml里的几个配置项。数据源配置不用说，核心就是URL、用户名、密码三项。MyBatis-Plus相关配置也需要明确：mapper-locations指向XML文件路径，logic-delete-field开启逻辑删除功能，map-underscore-to-camel-case保持默认true就行。

后端启动需要先确保MySQL里有对应的数据库和表。项目文档里一般会附带db/schedule.sql初始化脚本，直接执行即可。如果没有现成的SQL脚本，用MyBatis-Plus的自动建表能力也是一个备选方案，但建议核心的表还是手动设计，因为自动生成的表结构缺少索引和约束。

前端项目跑起来之前，需要npm install安装依赖。这里有一个提速技巧：npm换用国内镜像源后安装速度能快三倍以上。npm config set registry https://registry.npmmirror.com，执行这一条命令就够了。

前端环境的.env文件里配置接口地址。开发环境用Vite代理时，VITE_API_BASE一般是空字符串，因为请求会走相对路径/api；生产环境则要配置成完整的后端地址，比如http://localhost:8080/api。

实际启动流程建议是：先启动MySQL，再启动后端SpringBoot应用，最后启动前端Vite开发服务器。启动顺序不可逆的原因很简单：后端启动时要初始化数据库连接池，如果MySQL没起来，连接失败会导致启动中断；前端启动时不依赖后端，但如果你先启动前端再打开页面，此时后端还没就绪，页面会白屏或请求失败。

4.3 常见问题排查与避坑建议

整套系统最容易出问题的环节，我按踩坑频率排个序。

第一个高频问题是端口冲突。SpringBoot默认占用8080端口，如果你机器上已经有别的程序占用了8080，启动就会报Port already in use。排查方法用netstat -ano | findstr 8080（Windows）或lsof -i:8080（Linux）找到占用进程，要么kill掉，要么改掉SpringBoot的server.port配置。前端Vite默认5173端口也可能冲突，改Vite配置文件里的server.port就行。

第二个坑是数据库连接串没写对。jdbc:mysql://localhost:3306/schedule_db?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai，这个串要记住，后面那一堆参数缺一不可。useUnicode=true和characterEncoding=utf8保证中文不乱码，serverTimezone解决8.0时区报错问题。

第三个是MyBatis-Plus分页失效的问题。很多同学配置了分页插件但分页不生效，返回的结果是全量数据。原因几乎都是没有把PaginationInnerInterceptor加进MybatisPlusInterceptor，或者DbType写错了。我用过的正确写法是：

@Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; }

第四个坑是前端课表渲染时如果数据为空，应该显示“暂无课程”而不是白屏。我的做法是在课程格子渲染时判断Map里是否存在数据，不存在时显示一个灰色占位，这样视觉效果完整。

第五个是跨域问题。如果后端已经配置了@CrossOrigin但前端还是报跨域错误，多半是配置了多个跨域来源，或者拦截器提前拦截了OPTIONS预检请求。我的建议是后端只配置CORS的全局配置类，不要再用@CrossOrigin注解，避免冲突。

最后再分享一个和项目本身相关的经验。课表系统的排课冲突检测，我在第一版实现时只做了时间和星期的校验，漏掉了教室容量的校验。结果排课数据里出现了60人的班级进50人教室的情况，被指导老师一眼发现。所以建议大家在写排课校验逻辑时，把容量和教室类型的校验也一并提前设计进去，别等出了问题再补。

这个系统后续还可以做很多扩展。比如加一个调课审批的完整工作流，或者利用MySQL8.0的窗口函数做学期课表统计报表，甚至可以尝试用贪心算法做自动排课。对于想深入学习的同学，我的建议是先把现有代码读透，尤其课表冲突检测和课表渲染这两条线，然后找其中一个薄弱点做功能增强，会比新开一个项目更有积累价值。