SpringBoot+Vue+MySQL课表管理系统毕业设计全流程实战

每到大三下学期，我总能收到一堆关于毕业设计的私信，问得最多的就是"有什么系统能当毕设"。课表管理系统听起来像是个普通增删改查，但真动手做下去，从选题汇报到答辩PPT，处处都藏着坑。我完整跟过一套这样的项目——SpringBoot + Vue + MySQL三个主力技术拼出来的课表管理系统平台，从数据库设计、后端接口、前端课表渲染到打包部署，前后花了一个多月才打磨利索。这篇文章就把整个项目的拆解思路、核心设计逻辑和实操中踩过的坑原原本本写出来，适合正发愁选题、或者已经选了课表类管理系统的同学直接参考。

1. 为什么选课表管理系统当毕设：从选题逻辑到需求边界

1.1 毕设选题的三条硬标准

每年选题季都有同学在"太难做完"和"太简单没亮点"之间反复横跳。一个合格的毕设选题，至少要满足三条标准：工作量和难度匹配、技术栈主流、业务上有能讲深的东西。

课表管理系统恰好满足这三条。它不是一个纯粹的CRUD，里面藏着排课冲突检测、单双周课程、学期周次换算这些有业务深度的点，做出来之后你有东西可讲；同时它的功能边界又足够清晰，一个普通学生一两个月能做完，不会像"智慧校园平台"那样越做越失控。很多人觉得课表管理低端，其实恰恰相反，教务处排课在真实业务中是个非常繁琐的活，把这个问题解决好，本身就是亮点。

1.2 需求边界：三种角色，四类业务

我这套系统的需求边界是这样定的：整个平台服务于某高校的日常课表管理，参与角色有三种，管理员、教师、学生，三者通过权限区分。

• 管理员端：维护教师信息、班级信息、教室资源、课程信息，负责编排课表，处理排课冲突提示，发布学期课表。
• 教师端：查看自己的授课课表，按学期、周次筛选，查看授课班级和学生名单。
• 学生端：查看所在班级课表，切换单周/双周，查看课程详情和任课教师。

四类业务分别对应基础数据管理、排课管理、课表查看、登录授权。我刻意没加入调课申请、成绩录入这些扩展功能，一方面是为了控制工期，另一方面是让核心链路更扎实。做毕设最忌讳的是一开始什么都想加，结果每个功能都做得稀碎，答辩的时候被老师追问细节就露馅。

1.3 功能清单：先列全，再砍掉

我最初列的功能表里有十多项，包括教室借用、课程评价、消息通知，筛到最后只留了这些：

最后砍掉了教室借用和课程评价。原因很简单，排课、冲突检测、课表渲染这三块已经能支撑起整个系统的核心价值，把这三个做扎实，论文里足以写出三个像样的章节。功能不是越多越好，而是每做一个都要能讲清楚设计思路。

2. 技术选型的三方搭配：SpringBoot、Vue和MySQL各自凭什么上场

2.1 SpringBoot为什么取代SSM成为标配

很多同学纠结毕设用SSM还是SpringBoot。如果只看课程学习的深度，SSM能帮你理解框架底层；但如果看完成效率和答辩效果，SpringBoot明显更合适。

SpringBoot的优势在于自动配置和起步依赖，省掉了一大堆XML配置。以前SSM写一个完整的项目，要配Spring配置文件、SpringMVC配置文件、MyBatis配置文件，还要处理各种jar包版本冲突；SpringBoot用spring-boot-starter-web一个依赖就把Web环境拉起，你只需要关心业务代码本身。对毕设来说，时间是最大的成本，把省下来的配置时间投到业务逻辑和论文写作上，回报率高得多。

JDK版本我用的8，SpringBoot用的2.7.x。很多同学觉得越新越好，盲目去用JDK17和SpringBoot3，结果配一个Java环境就折腾半天，网上很多文档还是旧版写法，查问题都查不到答案。毕设场景讲求的是稳，选成熟的版本组合本身就是一种智慧。

2.2 Vue选2还是3，这是个实际决策

Vue我选了2.x加Element UI。原因很实在：Vue2的中文资料丰富，Element UI的组件和课表管理这类后台系统的匹配度非常高，表格、弹窗、日期选择器都是现成的。Vue3的组合式API确实更现代，但配套的Element Plus不少组件用法和Vue2版有差异，对一个以完成项目为首要目标的毕设来说，用最熟悉、资料最多的版本就是最优解。

前后端分离的项目结构，我用Vue CLI创建前端工程，配合vue-router做路由、axios做网络请求。后端只提供JSON接口，前端按页面需求去调。这种拆分的好处是边界清晰，前后端可以并行开发，而且答辩时只要讲清楚"前端如何调接口、后端怎么返回数据"这条链路，老师就知道你是真的理解了项目，而不是照着视频敲的。

2.3 MySQL的角色和版本选择

MySQL在整个系统里承担数据存储的主力，我用的是5.7版本。选5.7而不是8.0，同样是基于稳定性的考虑。5.7的驱动配置、字符集设置、Navicat连接都更顺滑，网上踩坑资料也最多。数据库设计上，我用了InnoDB引擎，utf8mb4字符集，事务隔离级别保持默认的REPEATABLE READ，这些基础设定能保证项目在大多数环境下不会出现莫名其妙的问题。

技术选型这块的答辩话术也很重要。老师问"为什么用MySQL而不是Oracle"，你要能回答：MySQL开源免费、轻量易部署、跨平台支持好，和SpringBoot的整合生态最成熟，对一个高校课表管理系统的数据量来说性能完全够用。这种问题不是考你会不会，而是看你有没有主动思考过"为什么这么选"。

3. 数据库设计：一张课程表怎么撑起整套课表业务

3.1 核心表结构：八张表的分工

数据库设计是课表管理系统的地基，也是答辩时老师最常盯着看的部分。我设计了八张核心表，分别是用户表、角色表、教师表、学生表、班级表、教室表、课程表、排课表。用户表存登录账号，教师和学生通过外键关联各自的业务表。

核心的排课表是整套系统的灵魂，它的结构直接决定排课逻辑能不能跑通。排课表我拆出来这些字段：

CREATE TABLE schedule_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, semester_id BIGINT NOT NULL COMMENT '学期ID', week_start INT NOT NULL COMMENT '起始周', week_end INT NOT NULL COMMENT '结束周', week_type TINYINT NOT NULL COMMENT '周类型 0全部 1单周 2双周', day_of_week TINYINT NOT NULL COMMENT '星期: 1-7', section_start INT NOT NULL COMMENT '开始节次', section_end INT NOT NULL COMMENT '结束节次', teacher_id BIGINT NOT NULL COMMENT '教师ID', course_id BIGINT NOT NULL COMMENT '课程ID', class_id BIGINT NOT NULL COMMENT '班级ID', classroom_id BIGINT NOT NULL COMMENT '教室ID', created_at DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_schedule (semester_id, day_of_week, section_start, classroom_id), UNIQUE KEY uk_teacher_time (semester_id, day_of_week, section_start, teacher_id, week_type) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='排课记录表';

3.2 周次和单双周：课表系统最容易被忽略的复杂度

第一次做课表系统的同学，十个里有九个把课表想简单了，以为就是"星期几、第几节"这两个字段。实际上高校课表有个麻烦的东西：单双周。同一门课可能是单周上、双周不上，也可能第一周到第八周每周都上，第九周开始换另一门课。

我设计的周次方案是三个字段配合：week_start和week_end记录起止周，week_type记录周类型。判断某周是否上课时，先看周次是否在区间内，再看单双周规则是否命中。如果周类型为0，表示每周都上；为1表示只在单周上；为2表示只在双周上。

public boolean isActiveInWeek(int targetWeek) { if (targetWeek < weekStart || targetWeek > weekEnd) { return false; } if (weekType == 0) { return true; } return (targetWeek % 2 == 1 && weekType == 1) || (targetWeek % 2 == 0 && weekType == 2); }

这段逻辑就是课表渲染的判定核心。前端要显示某一周的课表，后端拿到这周的数字，逐条判断排课记录是否生效。光是这个设计，就足够在论文里写出一节"周次判断算法"。

3.3 唯一索引：用数据库兜底冲突检测

排课表里我加了两组唯一索引。uk_schedule保证同一个教室在同一时间段只能有一门课，uk_teacher_time保证同一个教师在同一时间段不能被安排两门课。数据库索引是防重复的最后一道防线，就算应用层逻辑漏了，数据库也能挡住。

这里的细节是week_type也参与了唯一索引。为什么？因为同一间教室、同一时间、同一老师，如果周类型不同就可能不冲突，比如单周周一3-4节和双周周一3-4节是可以同时存在的，它们面对的是同一时刻但不同周的课。把week_type放进去，索引才能精确表达"哪些情况真正算冲突"。很多学生做课表的数据库设计时根本没想过单双周带来的索引差异，等到做排课冲突检测才发现逻辑怎么都绕不过去，回头改表结构，改得痛不欲生。

其他几张表的设计也花了心思。比如教师表和用户表分开，而不是直接在用户表里加role和teacher_name字段，是为了照顾一个教师可能有多个账号、或者账号绑定关系变化的场景；班级表存年级和专业，是为了课表按班级筛选时能直接展示层级关系。这些设计在答辩时都可以讲出"为什么"。

4. 后端核心模块：排课冲突检测是整套系统的技术门面

4.1 手工排课与冲突检测的实现思路

课表管理系统最核心的后端功能就是排课和冲突检测。手工排课的业务流程是：管理员选择学期、班级、课程、教师、教室，填写周次和节次，提交时后端先做一系列校验，然后写入排课记录。

冲突检测的逻辑我分成三层来写。第一层是基础格式校验，比如结束节次不能小于开始节次；第二层是同事段冲突检测，查询排课表看看这个教师、这间教室在当前学期、当前星期、当前节次范围内有没有冲突的课；第三层是周次交集判断，两条排课记录虽然都是周一3-4节，但一条是1-8周，一条是10-16周，那就不冲突，不用提示。

public void checkScheduleConflict(ScheduleRequest req) { List<ScheduleRecord> records = scheduleMapper.selectBySemesterAndTime( req.getSemesterId(), req.getDayOfWeek(), req.getSectionStart(), req.getSectionEnd()); for (ScheduleRecord record : records) { if (hasWeekOverlap(record, req)) { throw new BusinessException("排课冲突：时间段内已有课程安排"); } } }

冲突检测的要点是"时间重叠判断"。两门课的节次区间不一定完全一样，一门是3-4节，另一门是4-5节，它们的重叠节次是第4节，这种情况也必须视为冲突。所以查询条件要把section_start和section_end作为区间来处理，而不能只精确匹配。

4.2 接口设计和事务边界

后端接口我按资源维度进行RESTful风格设计。管理员发起排课用POST /api/schedule，查询课表用GET /api/schedule/table，这个接口接收学期、班级ID和可选周次参数，返回一个二维数组结构的课表数据。JWT登录用POST /api/auth/login，携带用户名密码，返回token。

写接口时我特别注重一个问题：失败原因要明确。排课接口失败的时候，到底是教师冲突还是教室冲突，接口要把具体原因返回给前端，前端才能在弹窗里提示用户。所以我定义了一个统一的返回体Result，包含code、message、data三个字段，code非0表示业务失败，message是给用户看的提示文案。

事务边界放哪也值得讲究。排课记录插入是单表操作，本身不用事务；但如果是"批量排课"功能，一次提交多节课，就必须加@Transactional，保证要么全部成功、要么全部回滚。我做过一个批量导入课表的功能，Excel解析出数据然后循环插入，如果不加事务，中间一条失败前面全白排了，页面显示部分成功，数据库里留下半截数据，查问题的时候头大得很。

4.3 权限控制：JWT配合自定义注解

权限我用的是JWT加Spring拦截器。登录成功后生成token，前端每次请求都在Header里带Authorization。后端用一个拦截器统一解析token，把用户信息存到ThreadLocal里供业务层使用。

角色控制我用了一个自定义注解@RequireRole，标注在Controller方法上，拦截器里判断当前用户角色是否匹配。比如排课接口只允许管理员访问，就加一个@RequireRole("ADMIN")。这种方法清晰实用，答辩时也好讲解：拦截器做什么事，注解怎么声明，切入点在哪里，三步讲完老师就懂了。

写后端的时候有一个心得：每个接口的返回数据尽量做到"刚好够用"，不要返超大JSON。比如课表查询接口，前端只需要课程名称、教师名称、教室名称、颜色标识，那就DTO只装这四个字段，不要把整张排课表全字段都吐出来。这样做的好处是前端代码更简单，接口响应更快，排查问题时返回结构也更清爽。

5. 前端实现：Vue组件如何把排课记录渲染成二维课表

5.1 课表矩阵的核心渲染逻辑

前端的重头戏是课表展示页面。原始数据是一堆排课记录，每条记录有星期、节次、周次、课程名、教师名、教室名，要把它们变成一张一眼能看懂的二维表格，横轴是星期一至星期日，纵轴是第1节到第12节，单元格里是课程信息。

我的做法是在前端维护一个7列12行的二维数组，遍历后端返回的排课记录，根据day_of_week和section_start定位到数组的对应格子，把课程信息填进去。多个格子合并的情况，比如一门课占了3-4节两行，我通过rowspan来合并单元格，这样课表看起来才符合学校教务系统那种长条格子的样式。

// 前端课表矩阵填充逻辑 const tableData = Array.from({ length: maxSection }, () => Array(7).fill(null)); records.forEach(item => { for (let sec = item.sectionStart; sec <= item.sectionEnd; sec++) { if (sec === item.sectionStart) { tableData[sec - 1][item.dayOfWeek - 1] = { ...item, rowspan: item.sectionEnd - item.sectionStart + 1, }; } else { tableData[sec - 1][item.dayOfWeek - 1] = { colspan: 0 }; // 占位，不显示 } } });

周次切换就是把这套渲染逻辑加上一个参数。页面顶部放一个周次选择器，传入第几周，后端把周次传给判断逻辑，只拉取该周有效的排课记录，前端不用改动渲染逻辑，只要重新请求数据重新填充矩阵。单双周的课程在矩阵里不会显示"单周""双周"的文字，而是通过切换周次自然出现和消失，这是最符合教务系统使用习惯的做法。

5.2 组件划分与页面结构

我把前端拆成几个页面和组件：系统布局用在Layout组件里做侧边栏和顶栏；登录页单独一个视图；班级课表页、教师课表页、排课管理页各是一个视图；排课弹窗和课程详情卡片抽成了通用组件。

组件化的好处是排课管理页和课表展示页可以复用很多代码。比如课程详情弹窗，在排课页点一条记录可以弹出来修改，在课表页点一个课程格子也能弹出来看详情，同一个组件两个地方用，写一遍就够了。前端的页面路由我配置了权限控制，未登录的访问统一重定向到登录页，管理员的路由单独加meta信息做角色拦截。

axios封装也是重点。我封装了一个request.js，统一设置baseURL、请求拦截器自动附加token、响应拦截器统一处理错误码。后端返回code非0时，前端直接弹出ElMessage提示错误信息，401时自动清除token并跳转登录页。这些基建虽然不起眼，但决定了前后端协作的效率和质量。

5.3 联调阶段最容易忽略的细节

联调的时候遇到过几个值得注意的点。第一个是跨域问题，前端开发服务器跑在8080端口，后端跑在9090端口，前端请求后端必须配跨域。我做了两个方案：后端用CorsFilter配置允许跨域，本地开发用Vue CLI的proxy代理转发，上线时proxy不生效，后端跨域配置兜底。

第二个是课表时间显示的格式问题。后端返回的日期和时间为空值，前端三元表达式要写好判空，否则页面上出现一堆"undefined"看着就像烂尾工程。

第三个是课表格子的颜色区分。我给不同课程类型分配了不同的背景色，比如公共课用浅蓝色、专业课用浅橙色、体育课用浅绿色，这个不是功能需求，但是非常影响答辩的第一印象。老师打开你的系统看到一张井然有序、色彩分明的课表，和看到一张白底黑字挤成团的表格，完全是两种评价。

6. 部署流程和论文结构：毕设答辩前的两个最后关卡

6.1 从开发到部署的完整链路

部署这件事，很多同学拖到最后才搞，结果各种环境问题搞得手忙脚乱。我的建议是项目开发到一半就先把本地打包流程跑通，后面每次迭代都顺手验证一遍。

部署方案我用的是最经典的双服务方式：后端SpringBoot打成jar包，前端Vue构建成dist静态文件，用Nginx托管。数据库脚本用Navicat导出成SQL文件，部署时在新环境里执行一遍就能建好所有表。

后端打包前要注意几个配置：application.yml里的数据库连接要改成目标服务器的地址，端口要留意有没有被占用，JWT密钥在正式环境要换掉默认值。打jar包用Maven的package命令，生成的文件在target目录下，用java -jar命令启动即可。

前端构建是npm run build，生成dist目录，里面是静态资源。Nginx的配置有一个常见的痛点：直接配置root指向dist后，刷新某个子路由页面会404。因为Vue是单页面应用，路径切换靠前端路由，刷新时Nginx会按真实路径找文件，找不到就404了。解决办法是配置try_files把所有路径都指向index.html：

location / { root /home/student/www/dist; index index.html; try_files $uri $uri/ /index.html; }

数据库迁移这一块，建议用版本号命名脚本，比如v1_init.sql、v2_add_teacher.sql，每改一次结构就生成一个新脚本。我是踩过没留脚本的坑的，开发阶段的表结构完全靠Navicat手动改，后面换电脑部署时报错找不到字段，查了半天才知道是数据库结构不一致。写论文的时候把数据库脚本作为附录，这也是加分项。

6.2 论文结构：五章内容怎么分布

论文我采用的是经典的"绪论-相关技术-系统设计-系统实现-测试"五章结构，每一章内容都对应到实际代码和截图。

绪论里着重写课题背景和研究意义，这部分不要空谈"随着信息技术的发展"，而是从实际的排课烦恼写起。教务人员用Excel排课的痛点是什么？课程冲突人工检查容易出错、调课信息同步不及时，这些问题就是系统要解决的现实需求。

相关技术章节把SpringBoot、Vue、MySQL三件套分别介绍，每个框架写清楚"核心特性"和"在本项目中的角色"，这样技术选型才有着落，不是背百度百科。

系统设计章节是论文最硬的部分，包括整体架构图、模块设计、数据库设计、核心算法设计。尤其是排课冲突检测和单双周判断这两块，画好流程图、设计好表结构，这段内容能占系统设计的一半篇幅。系统实现章节配核心功能截图，每个功能配核心代码片段，代码不要整段贴，截取关键逻辑配上文字说明就好。测试章节写测试环境、测试用例和测试结论，用表格列清楚。

6.3 答辩自述的思路：从问题出发讲系统

答辩自述一般控制在5到8分钟。我的建议是不要按论文目录逐章念，而是从问题出发讲系统：学校排课有哪些痛点、我的系统怎么解决、核心表结构和算法怎么设计的、最终效果如何。这条线讲下来，比"首先介绍了…然后使用了…"的流水账要好得多。

关于答辩的高频问题，要提前准备好答案。比如"排课冲突是怎么检测的"、"单双周怎么处理"、"和手动Excel排课相比优势在哪"、"系统最多能支持多少数据量"。这些问题都是在实际开发中遇到的，只要你是真做的，就能答上来。最大的雷区是不要夸大系统能力，什么"高并发""分布式"这些词千万别提，一个课表管理系统谈什么高并发，反而让老师觉得你在背概念。

7. 开发中真实踩过的坑：时区、空格、单双周判断这些坑各有解法

7.1 数据库时区和连接串参数

第一个让我折腾了半天的坑是数据库连接串。本机连MySQL一切正常，换了一台电脑部署后，启动报错"Server returns invalid timezone"。这是MySQL8.0和5.7的驱动行为差异造成的，解决方法是连接串里加serverTimezone=Asia/Shanghai。虽然我本地用的是5.7，但项目里引入了高版本的MySQL驱动，底层行为还是按高版本走。这个问题很多同学都会遇到，在配置里显式指定时区就能稳定复现解决。

7.2 中文乱码的排查顺序

中文乱码这个问题，前端页面表单提交后中文显示成问号，我当时排查了很久。最后发现是三个层面都要处理：数据库连接串加characterEncoding=utf8；数据库表和字段的字符集是utf8mb4；前端请求的Content-Type要显式声明application/json;charset=UTF-8。三层缺一个都可能出问题。这个排查顺序也值得记下来，遇到乱码先从这三处对比检查，不要盲目改代码。

7.3 单双周的边界条件和排课冲突查询缺失

单双周这个功能，写isActiveInWeek方法的时候看着很短，很多同学抄下来就忘掉了边界测试。我列了一些边界用例：第一周算不算单周、学期总周数是奇数还是偶数、weekStart是2且weekEnd是9时单双周怎么分布。如果不专门测试，很可能会出现第9周该停的课还在显示、或者第1周该上的课消失了的bug。给这段逻辑写一个简单的单元测试，几个断言就能覆盖住，比手工点页面点半天靠谱得多。

排课冲突查询是我另一个踩坑点。一开始我写的SQL是精确匹配section_start = ?，后来发现3-4节和4-5节这种部分重叠就漏掉了。改成区间重叠判断之后，还要注意一个细节：查询条件要同时查sectionStart <= 新记录的结束节次 AND sectionEnd >= 新记录的开始节次，这样才能覆盖所有重叠情况。这个改造完，冲突检测才算真正可靠了。

7.4 打包发布的缓存问题

前端每次改完代码重新构建部署，用户在浏览器里打开还是老页面，这是Nginx静态资源缓存导致的。解决方法是Nginx配置里针对index.html关闭缓存，其余的静态资源文件名用Vue构建时的hash值，文件内容变了hash就变，浏览器自然就会拉取新资源。这些是上线阶段的知识，但开发时提前处理好会省下大麻烦。

还有一次印象特别深的是部署后接口偶发报错，查看日志发现是数据库连接池耗尽。排查下来是后端默认的HikariCP最大连接数只开了10，而前端页面多发了几次重试请求就占满了。解决方案是把最大连接数调到50，同时前端axios做了请求超时和取消重复请求的处理。这种问题开发环境很难遇到，只有部署后真实使用才会暴露，写进论文的测试章节也是一个不错的素材。

做完这套课表管理系统，我最深的体会是：做毕设不要贪功能多，而要把核心链路打通、做扎实。排课冲突检测、单双周判断、课表矩阵渲染这三个核心点，每一个都值得花时间仔细打磨，它们才是你在答辩时最有底气讲的东西。最后再分享一个小技巧：所有踩过的坑都随手记在开发日志里，写论文的测试总结章节时，这些记录直接就是素材，省得最后回头回忆"当初那个bug是啥来着"。祝各位做完这套项目之后，答辩顺顺利利过。