课表管理系统毕设全攻略：SpringBoot+Vue+MySQL从设计到部署

课表管理系统大概是计算机毕业设计里“点单率”最高的题目之一了。你随便一搜，满屏都是SpringBoot+Vue+MySQL的源码和论文，但真拿到手能跑通、能讲清楚、能过答辩的，其实没几个。我前阵子帮人把一套西安工商学院的课表管理系统完整地走过一遍——从源码、数据库、论文到部署文档全部整理干净——过程中踩了不少坑，也摸清了这类毕设项目的核心逻辑。这篇博客就围绕这套系统的完整落地过程，把选型思路、数据库设计、前后端实现、部署交付到论文答辩的各个关键环节全部过一遍。想拿来做毕设参考，或者想搞清楚一个前后端分离项目是怎么从零到一交付的，这篇应该能帮你省很多力气。

1. 项目整体拆解：从题目到需求，先把思路理顺

1.1 选题评估：为什么“课表管理系统”值得做

很多同学选毕设题目的时候有个误区，觉得“管理系统”太普通、太没技术含量。但实际答辩时你会发现，老师最看重的不是题目多花哨，而是你能不能把需求分析、架构设计、表结构设计、接口设计、异常处理这些东西讲得头头是道。课表管理系统恰恰能把一套标准的信息管理系统“该有的东西”都覆盖到：多角色权限、复杂的数据关联、核心业务逻辑（排课冲突检测）、前端表格交互、数据可视化。它看起来朴素，但五脏俱全，特别适合用来展示你对全栈的掌握程度。

另外课表管理系统有一个天然的好处——需求非常明确，不用像“智能推荐系统”那样还要自己编造数据来佐证效果。教室、教师、课程、班级、时间，这些要素每个人在学校里都接触过，需求方（答辩老师）也熟悉，容易理解你的设计逻辑，沟通成本低。做出来之后效果好不好，看课表界面一眼就能判断，演示起来非常直观。

1.2 技术选型的为什么：SpringBoot + Vue + MySQL的组合逻辑

接下来聊技术栈。为什么这套项目是 SpringBoot + Vue + MySQL，不是 Spring + JSP，也不是 Flask + React？说到底就是三个字：好交付。

SpringBoot 帮你去掉了 Spring 时代那套繁琐的 XML 配置，内嵌 Tomcat，一个 JAR 包扔上去就能跑，这对毕设项目来说太关键了。因为答辩现场演示时，你最怕的就是“环境配置半小时，系统起不来”。Vue 配合 Element UI（或 Element Plus）写管理后台的效率非常高，表格、表单、弹窗这些组件都是现成的，前端代码量能压缩到一个很舒服的量级。MySQL 就不用说了，免费、装起来简单、网上资料多到爆炸，出了问题搜一下就有答案。

前后端分离的架构在答辩时也是加分项，因为绝大部分同学做的还是 JSP 这种前后端耦合的老项目。你讲了 Vue 的组件化、Axios 请求、跨域处理、JWT 身份认证，老师一听就知道你是跟得上技术趋势的。换句话说，这套组合让你在实现难度不算高的情况下，技术评分上限反而更高。

1.3 角色与功能模块梳理：白板画图是最快的分析方法

拿到题目先别急着写代码，找一个白板（没有白板就用一张A4纸），把系统里涉及的角色写出来。这套系统核心角色就三个：管理员（教务人员）、教师、学生。然后围绕每个角色问三个问题：他登录进来要看到什么？他要做什么事？他做的操作会影响什么数据？

我的梳理结果是这样的。

管理员：管理教师信息、学生信息、班级信息、课程信息、教室信息，负责安排课表、调整课表、发布课表。

教师：查看自己的课表、查看所带课程的选课学生名单、申请调课。

学生：按班级查看课表、查看个人课表（选课后）、空闲教室查询（可以当加分项）。

这三条线理清楚后，功能模块就自然出来了：系统管理模块（用户角色权限）、基础信息管理模块（教师、学生、班级、教室、课程）、排课管理模块（核心）、课表查询模块（PC端）。

记住这个经验：功能模块表别等写代码的时候再画，前期理清，后面写论文也能直接用，一鱼两吃。

2. 数据库设计与后端核心实现：这是决定上限的部分

2.1 核心表结构设计详解

数据库设计是这套系统的灵魂。很多同学的表结构就是一张课表记录表，字段堆一堆，结果排课时怎么查冲突都别扭。我设计这套系统的时候，把表拆成了两层：基础数据层和业务数据层。

基础数据层主要是五张表：

• sys_user：用户表，字段包含 user_id, username, password, role（角色），role 建议用字符串类型直接存 ADMIN、TEACHER、STUDENT，别用数字字典，毕设系统没必要搞那么复杂，查询时还要关联字典表反而麻烦
• teacher：教师表，关联 user_id，存工号、姓名、职称、所属学院
• student：学生表，关联 user_id 和 class_id，存学号、姓名、性别
• class_info：班级表，存班级名称、所属学院、年级
• course：课程表，存课程名称、课程编号、学时、学分、开课学院
• classroom：教室表，存教室编号、位置、容量、类型（普通/多媒体/实验室）

业务层核心就一张大表 course_arrangement（排课记录表），但它的品位决定系统质量。我推荐的字段设计是这样：

sql复制CREATE TABLE course_arrangement (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    course_id BIGINT NOT NULL COMMENT '课程ID',
    teacher_id BIGINT NOT NULL COMMENT '教师ID',
    class_id BIGINT NOT NULL COMMENT '班级ID',
    classroom_id BIGINT NOT NULL COMMENT '教室ID',
    week_day TINYINT NOT NULL COMMENT '星期几 1-7',
    section_start TINYINT NOT NULL COMMENT '开始节次 1-12',
    section_end TINYINT NOT NULL COMMENT '结束节次',
    semester VARCHAR(20) NOT NULL COMMENT '学期，如2024-2025-1',
    week_start TINYINT NOT NULL COMMENT '起始周',
    week_end TINYINT NOT NULL COMMENT '结束周',
    UNIQUE KEY uk_classroom_time (classroom_id, week_day, section_start, week_end, semester),
    UNIQUE KEY uk_teacher_time (teacher_id, week_day, section_start, week_end, semester)
);

我把 UNIQUE KEY 写在这里，就是为了给排课时的冲突检测“兜底”。你在界面上可以弹窗提示“该教室该时段已被占用”，但要是两个用户同时操作或者代码里漏了判断，数据库的唯一键还能拦一道。这是实战中非常重要的兜底思维，数据库永远要作为最后一道防线。

2.2 排课冲突检测的逻辑实现与SQL写法

课表管理系统的核心难点不在 CRUD，在排课。排课的本质是一个约束满足问题：一个教师同一时间只能在一个教室上课，一个教室同一时间只能容纳一个班级，一个班级同一时间只能上一门课。

我用一个例子来说明冲突检测的 SQL 逻辑。假设现在要在“星期四第3-4节”给“软件工程1班”排一门课，教师是“张老师”，教室是“A101”。你要检查的就是三件事：

sql复制-- 检查教室冲突
SELECT COUNT(*) FROM course_arrangement
WHERE classroom_id = 1
AND week_day = 4
AND week_start <= 10 AND week_end >= 10
AND section_start < 4 AND section_end > 3
AND semester = '2024-2025-1';

-- 检查班级冲突
SELECT COUNT(*) FROM course_arrangement
WHERE class_id = 2
AND week_day = 4
AND section_start < 4 AND section_end > 3
AND semester = '2024-2025-1';

-- 检查教师冲突
SELECT COUNT(*) FROM course_arrangement
WHERE teacher_id = 3
AND week_day = 4
AND section_start < 4 AND section_end > 3
AND semester = '2024-2025-1';

注意这里用了一个通用的区间重叠判断公式：section_start < 新结束 AND section_end > 新开始。这个公式很强，能覆盖所有重叠情况：新排的3-4节和已有的1-2节不重叠，和3-4节完全重叠，和2-5节部分重叠，都能正确判断。不要自己写 start BETWEEN old_start AND old_end 这种分段判断，容易漏边界。我在这套系统里就是把这个SQL封装成一个service方法，排课和调课都复用这一套。

区间重叠判断这个细节，在论文里一定要大讲特讲，因为这是你系统里真正有技术含量的业务逻辑，答辩老师问到排课模块时，你能说出这套判断公式，比你背十个八股文都管用。

2.3 SpringBoot后端：分层结构与接口设计经验

后端我用的是标准的三层架构：Controller → Service → Mapper，配合 MyBatis-Plus 使用。说句实话，纯手写 MyBatis XML 在毕设阶段效率太低，MyBatis-Plus 的 BaseMapper 把单表 CRUD 全包了，你只需要用 LambdaQueryWrapper 写条件查询。

举个例子，查询某教师本学期课表，代码可以写成：

java复制public List<ArrangementVO> getTeacherTimetable(Long teacherId, String semester) {
    LambdaQueryWrapper<CourseArrangement> wrapper = new LambdaQueryWrapper<>();
    wrapper.eq(CourseArrangement::getTeacherId, teacherId)
           .eq(CourseArrangement::getSemester, semester)
           .orderByAsc(CourseArrangement::getWeekDay)
           .orderByAsc(CourseArrangement::getSectionStart);
    List<CourseArrangement> list = baseMapper.selectList(wrapper);
    // 再循环补全课程名称、班级名称、教室名称
}

注意联表查询的问题。很多新手习惯用 @TableField(exist = false) 在实体类里加一个 courseName 字段，然后嵌套循环去查字典表，这种做法数据量小的时候没问题，但会有一条经典的“N+1”查询问题。我的建议是排课列表这种高频查询的接口，直接用自定义SQL联表查，一次 JOIN 把课程名、教师名、班级名、教室名全部带出来，返回给前端的 VO 对象里全都有，省心省力。系统里基础列表接口我用的 MyBatis-Plus，课表查询这种复杂接口我用自定义SQL，两种手段结合，代码既有开发效率又有查询效率。

后端代码里必须要处理的一件事情是异常统一返回。我写了全局异常处理器 @RestControllerAdvice，自定义了一个 BusinessException，排课冲突时就抛这个异常，前端统一弹提示。千万不要在 Controller 里 try-catch 到处透传错误信息，那样代码丑且难维护。

登录认证用的是 JWT。本来用 Spring Security 是最正规的，但毕设项目我建议直接用拦截器 + JWT 工具类，理由很简单：Spring Security 的过滤器链、权限配置那一套，学习成本高，配置写不好反而把自己坑了。用拦截器只需要在配置类里注册一下要拦截的路径，JWT 工具类负责生成和校验Token，简单容易讲清楚，答辩的时候解释起来也流畅。

核心的拦截逻辑就是：

java复制@Component
public class JwtInterceptor implements HandlerInterceptor {
    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) {
        String token = request.getHeader("Authorization");
        // 校验token，合法放行，不合法返回401
    }
}

3. 前端Vue实现要点：课表页面才是门面

3.1 项目初始化和通用封装

前端我用 Vue 2 + Element UI 这套组合，别急着喷“怎么不用 Vue 3”，毕设用 Vue 2 是相当稳妥的选择。Element UI 的组件库成熟，网上资料多，遇到坑好搜索。组件库里的 el-table、el-form、el-dialog、el-select 这些组件，几乎覆盖管理系统所有场景。

前端工程结构我是这样组织的：api 目录放接口定义，router 目录放路由，store 目录放 Vuex 状态，views 目录放页面组件。这样组织的好处是，写论文的时候“前端工程技术”这一节有东西可写，面试官或答辩老师问你代码怎么组织的，你也能答得清楚。

通用封装必须做两件事。第一件，Axios 实例统一创建，设置 baseURL 和请求拦截器，在拦截器里把 Token 放到请求头，响应拦截器里统一处理 401、500 和业务错误码。

javascript复制import axios from 'axios';
const service = axios.create({
    baseURL: '/api',
    timeout: 10000
});
service.interceptors.request.use(config => {
    const token = localStorage.getItem('token');
    if (token) {
        config.headers['Authorization'] = token;
    }
    return config;
});
service.interceptors.response.use(
    response => response.data,
    error => {
        if (error.response && error.response.status === 401) {
            router.push('/login');
        }
        return Promise.reject(error);
    }
);

第二件，按后端模块把接口统一封装成函数。比如排课管理模块的接口就是一个独立的 arrangement.js 文件，页面里调用 import { getTimetable, createArrangement } from '@/api/arrangement'。不要在页面组件里直接写 axios.get(...) 大段重复代码，后期维护会让你怀疑人生。

3.2 课表可视化：核心页面的渲染思路

课表页面是这套系统的门面。我的实现思路是：拿到后端返回的排课记录列表后，前端转换成一个 7行 × 12列 的二维数组结构，行代表星期一到星期日，列代表第1节到第12节。然后使用 el-table 渲染，把合并单元格的班级、课程、教室等信息拼接在表格里。

核心代码大概是这个意思：

html复制<el-table :data="timetableRows" border>
  <el-table-column label="时间">
    <template slot-scope="scope">{{ scope.row.label }}</template>
  </el-table-column>
  <el-table-column v-for="day in days" :key="day" :label="day">
    <template slot-scope="scope">
      <div v-if="scope.row.courses[day]">
        {{ scope.row.courses[day].courseName }}
        <p>{{ scope.row.courses[day].teacherName }}</p>
        <p>{{ scope.row.courses[day].classroomName }}</p>
      </div>
    </template>
  </el-table-column>
</el-table>

这里有个小经验：有些同学用 v-for 嵌套遍历所有排课记录去匹配单元格，性能很差，页面一度卡到爆炸。先转换成二维数组再做渲染，渲染时只需要根据当前行和当前列直接拿到课程对象即可，一步到位。

3.3 前端联调的几个易错点

前后端联调阶段我每次都会被学生问到几个相同的问题，这里提前列出来。

第一个是跨域。开发环境下，前端运行在 localhost:8080，后端在 localhost:9090。解决方案有两种：要么后端配 @CrossOrigin 或者 CORS 过滤器，要么前端配置 Vue 的 devServer 代理，把 /api 路径代理到后端地址。我推荐用前端代理方案，因为这样上线后部署到 Nginx 还可以顺便解决跨域，前后端统一走反向代理。

第二是路由刷新 404。用 history 模式路由时，部署到服务器后刷新页面会出现 404，因为路由只是前端模拟的路径，后端服务器没有对应的物理文件。解决方案是在 Nginx 配置里加上 try_files $uri $uri/ /index.html;。这个细节在部署文档里一定要写清楚，很多同学卡在这一步卡了一下午。

4. 部署与交付：从源码到可运行系统的最后一公里

4.1 环境准备与本地运行

一个毕设项目交付的时候，最尴尬的情况就是你发个压缩包过去，对方解压后根本跑不起来。所以我说部署文档绝对不能敷衍，环境版本信息必须写明。

我们这套系统的环境基线是：JDK 1.8、Maven 3.6+、Node.js 14+、MySQL 5.7 或 8.0（5.7 更稳）、Nginx 1.20+。注意 MySQL 8.0 和 5.7 的驱动配置、时区配置是有差异的，我建议干脆统一用 5.7，兼容性问题最少。

本地跑起来分四步。第一步，导入 sql 目录下的数据库脚本，脚本里包含了建表语句和基础测试数据（账号：admin/123456）。第二步，用 IDEA 打开后端工程，修改 application.yml 里的数据库连接配置，然后启动 SpringBoot 应用。第三步，在前端工程目录执行 npm install（这一步如果网络慢或报错，多半是 npm 源的问题，切换成国内镜像源就行），然后执行 npm run dev。第四步，浏览器访问 http://localhost:8080，用管理员账号登录。能在本地跑通之后，再考虑部署到服务器。

4.2 前后端分离部署的精简方案

部署时不需要搞得很复杂，我推荐一个最经典的方案：后端打 JAR 包，前端打包成静态文件放在 Nginx 里，用 Nginx 做反向代理。后端的打包命令是在项目根目录执行 mvn clean package -DskipTests，打出来的 jar 文件直接用 java -jar 启动。

前端执行 npm run build，生成 dist 目录，然后把 dist 里的文件拷贝到服务器的 Nginx 静态目录，比如 /usr/share/nginx/html。Nginx 配置是很多人第一次接触的东西，我把经典配置贴在这里，一个 location 指向前端静态资源，另一个 location 把 /api 转发到后端服务：

nginx复制server {
    listen 80;
    server_name yourdomain.com;

    root /usr/share/nginx/html;
    index index.html;

    location / {
        try_files $uri $uri/ /index.html;
    }

    location /api/ {
        proxy_pass http://127.0.0.1:9090/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

留意 proxy_pass http://127.0.0.1:9090/; 最后面那个斜杠，有斜杠表示把 /api 前缀去掉再转发。也就是前端请求 /api/arrangement/list，后端收到的实际就是 /arrangement/list。这个细节如果不注意，接口路径就会多一段 api，直接后端 404。

4.3 数据库交付注意事项

数据库交付是整个交付环节中最容易被忽略的一环。很多同学直接把自己本地 MySQL 的 data 文件夹拷贝过去，然后在对方电脑上死活挂载不上，崩溃。正确做法是导出 SQL 脚本。

导出时要确保包含两部分：建表语句（CREATE TABLE）和种子数据（基础的管理员账号、班级、测试课程等）。注意用 Navicat 导出时，为了能在对方环境直接导入成功，有几项必须检查：字符集统一 utf8mb4；外键约束、触发器、存储过程看情况导出，毕设项目一般用不上触发器，导不导无所谓；表结构里不要有依赖本地路径的字段或函数。

种子数据太重要了，演示时如果发现课表页面空空如也，十有八九是没导入种子数据。我一般会在系统里准备好一个学期的完整测试课表：3个年级、6个班、20门课程、10位老师、8个教室，让学生登录进去直接能看到排版漂亮的课表。

还有一个很隐蔽的坑是 MySQL 时区。连接数据库的 URL 里如果没有指定 serverTimezone，使用 MySQL 8.0 时 JDBC 驱动会报一个 The server time zone value... 的异常，系统接口全部 500。加上 ?serverTimezone=Asia/Shanghai 就能解决。

5. 常见问题排查实录与答辩准备

5.1 高频Bug排查速查表

我把这套系统从开发到答辩过程中遇到的高频问题整理成了一张速查表，任何一个问题卡住超过30分钟，都可以对照这个表来找思路。

每一条我都在真实项目中遇到过。其中“接口返回中文乱码”和“部署后刷新404”是最能浪费时间的两类问题，强烈建议在部署文档里单独写出来，对方遇到时直接查表定位。

5.2 论文写作的章节安排和技巧

论文不是代码写完了再补的，它的章节骨架应该和开发过程同步推进。标准的论文结构是：绪论（研究背景与意义、国内外研究现状）、相关技术介绍、需求分析、总体设计、数据库设计、详细设计与实现、系统测试、总结与展望。

写的时候记住一条核心原则：论文不是代码的流水账，它的任务是“解释为什么这么设计和怎么实现关键功能”。相关技术介绍那章，不要抄官方文档式的介绍，你写了 SpringBoot、Vue、MySQL 各自是什么，这没意义。要写的是“为什么用 SpringBoot 而不用传统 SSM”“为什么用前后端分离”“这套组合怎么支撑课表管理系统的需求”。每一段都带着项目语境去写，论文质量自然提升。

数据库设计这章建议多放图：ER图、表结构图、核心表字段说明表格。答辩老师翻论文时，看得最快的就是图表。排课模块的时序图也要画一张，展示排课请求从页面到后端到数据库再到返回的完整流程，这张图能大幅提升论文的专业感。

5.3 答辩演示的顺序把控

答辩现场演示是最能拉开差距的环节。我的建议是排课系统控制在 8 分钟以内，按以下顺序来：登录演示（顺带展示不同角色的权限差异）；基础数据管理（快速展示教师、班级、教室模块的增删改查）；排课管理（现场排一门课，故意制造一下冲突，展示冲突检测的弹窗提示，这是全场最佳亮点）；课表查询（切到学生或教师角色，展示课表页面）；最后可以展示一下部署后的线上访问效果。

演示时一定要提前准备好“后手”素材：万一现场网络不稳定，前后端分离的情况下前端页面起不来，提前在浏览器本地缓存一份完整截图和动图；数据库连不上时，有备好的 SQL 文件可以直接重新导入。我还见过一个同学，答辩前把整个系统跑通后的截图全部导出为一个 PDF，放在桌面当应急预案，这就是非常聪明的做法。

调试的过程中我发现一个有意思的事情：真正理解排课系统的人，往往是因为自己动手设计过排课算法的那一版，哪怕它后来被重构了。你踩过的坑、想不通的业务场景、调试到深夜的冲突检测，这些真实经历远比最后那几行代码更有价值。去复现别人代码时，别满足于“跑通了”，多问一句“为什么字段要这么设计”“为什么这里要幂等”，这些带着答案的疑问，往往是答辩现场你最自然的自信来源。

最后再分享一个关于交付文档的小细节：压缩包命名别叫 新建文件夹.zip，文件名建议写成 课表管理系统_源码+数据库+论文+部署文档.zip，里面再分四个子目录：源代码、数据库、论文、部署文档。另外给数据库脚本文件里的注释写清楚测试账号，给部署文档加一个目录，打包时顺手把读我README.md放进去，写清楚环境要求、运行步骤、常见问题。这个小习惯看似不起眼，但收到你项目的人，第一印象就是“这个人做事靠谱”。课表管理系统只是载体，真正让你不被别人替换掉的东西，是你能把整个交付链条做完整的能力：需求、设计、编码、测试、部署、文档，哪一环都经得起推敲。