企业官网建设流程全解析

毕业设计这种事，每年都有一批人栽在同一个坑里：题目看着简单，一上手才知道课表系统的水有多深——排课冲突、教室占用、教师时间、周次单双周，随便一个逻辑绕进去就是两三天出不来。我之前帮人审过不少这类项目，SpringBoot、Vue、MySQL 这个技术栈本身不新鲜，但放在课表管理这个场景下，真正能跑顺、能过答辩、能拿给老师演示的版本，反而没想象中那么多。这篇文章就围绕一个我实际跟进的某高校课表管理平台来拆解：从选题动机、表结构设计、后端接口编写，到前端课表网格渲染、部署上线和论文答辩，把整个链路里值得复制的东西和一踩就翻车的细节都写清楚。适合正在做同类毕设、想在前人基础上快速搭骨架的同学，也适合那些拿到一套现成源码但不知道怎么改、不知道怎么答辯的人。

1. 为什么课表系统是“看起来简单、做起来折磨”的典型毕设题

先说个反直觉的结论：课表管理系统在毕设选题里属于那种“人人觉得自己能做，但很多人做到一半就换题”的项目。原因在于，大家第一反应是“这不就是个CRUD吗”——学校、班级、教师、课程、时间几个表互相查一下就行。但真正把需求跑一遍，你会发现事情完全不一样。

1.1 课表的“五个维度”才是核心难点

课表管理的业务本质是处理五个维度之间的关系：班级、教师、教室、课程、时间。任何一门课要落到课表上，必须保证这五个维度在同一个时间点上不冲突——两个班不能共用同一间教室，一个老师不能同时上两门课，一个教室不能同时被两门课占用，班级自身也不能同一时间排两门课。如果课程还分单双周、分前八周后八周，这个冲突判断的逻辑复杂度会直接翻倍。

很多同学一上来就写一个insert接口，把课程信息塞进表里就觉得完成了核心功能，结果一测试就露馅：课表上同一个教室出现了两门课，或者某个老师的时间段重叠。这种问题不是前端样式能掩盖的，它直接暴露的是“业务逻辑模型没想清楚”。

我在这个项目里最先做的事情，不是写代码，而是把排课冲突的校验规则单独拎出来，做一个独立的服务类。这样无论是管理员在后台手动排课，还是未来做自动排课，都可以复用同一套校验逻辑。校验对象也不只是“时间是否重叠”，还包括周次重叠、节次重叠、教室是否被占用、老师是否存在安排、班级是否已有课程，五个方面全部通过才允许写入。

1.2 前后端分离还是服务端渲染：毕设到底怎么选

市面上能看到的类似系统，大体分两种形态：传统的 JSP/Thymeleaf 服务端渲染，以及目前更主流的 SpringBoot + Vue 前后端分离。如果你问我的建议——除非你们学校明确要求必须用某种技术，否则直接选前后端分离，理由非常现实：

第一，前后端分离的结构在论文里更好“讲故事”。你可以清清楚楚地拆出“前端负责视图交互”“后端负责业务逻辑与接口”“数据库负责持久化”，每一章都有内容可写。第二，找参考代码也容易，SpringBoot 的 REST 接口加 Vue 的单页应用是市面上最泛滥的组合，遇到问题搜一下全是答案。第三，部署文档写起来也直观，前端打包成静态文件丢进 Nginx，后端打成 jar 包运行，MySQL 导一份初始化脚本，三步走通。

这个项目用的就是 Vue 2 + Element UI，后端 SpringBoot 2.7.x，数据库 MySQL 5.7。这套组合虽然不算新，但胜在稳，资料多，答辩时老师问什么都能接住。

1.3 拿到一套源码之后，先干三件事

如果你是那种“已经拿到源码，正在想办法改成自己的”同学，我的第一个建议是：不要急着去改页面上的学校名称和 Logo，先把系统的表结构完整看一遍。花一小时把数据库里的每个表、每个字段和你自己的需求比对一遍，搞清楚哪些表是核心表、哪些是附属表，比你盲目改十个前页面有用得多。

头像与个人信息表、用户表、角色表这种基础结构一般不用动，真正需要改的是课程表、班级表、教师表、教室表、排课记录表之间的关联字段。举个例子：如果原来的系统里教室表没有“容量”字段，你要做合班上课就做不了；如果课程表没有“周次类型”（比如 single/double/total），单双周排课就是空谈。这些属于骨架级别的差异，越早发现越好改。

2. 数据库设计：先解决“一张课表怎么落库”的问题

数据库是整个系统里最能拉开差距的地方。课表系统的表结构，核心并不在于张数多，而在于关系足够清楚。我的做法是先定核心实体，再围绕排课冲突这个刚需去补辅助字段，最后才考虑扩展功能。

2.1 核心表拆解：用户、教师、班级、教室、课程、排课

基础表通常包括这几类：

用户表（sys_user）：存放登录账号、密码（BCrypt 加密存储）、角色标识、关联的教师或学生 ID。角色这里我建议至少分三种——管理员、教师、学生，不搞太细，答辩时好解释，权限控制也不至于写得太过复杂。

教师表（teacher）：教师编号、姓名、所属学院、职称、联系方式。注意教师编号最好做成唯一业务键，排课关联时用教师 ID，展示时用编号。

班级表（class_info）：班级名称、所属专业、年级、人数。别把班级和专业混成一张表，否则后面按专业查课表、按年级统计班级数量都会变得很别扭。

教室表（classroom）：教室编号、所在校区/教学楼、楼层、容量、类型（普通教室/多媒体/机房），还应该加一个 is_available 字段用于实现停用教室的逻辑。

课程表（course）：课程名称、课程编号、学分、学时、课程性质（必修/选修）。学时字段后期和排课表关联后，可以用于做教师工作量统计，这个点是很多论文的加分项。

排课表（schedule）：这条是核心中的核心，后面的段落我会单独展开。

2.2 排课表字段设计：节次、周次、单双周的存储策略

排课表我把字段定为：id, course_id, teacher_id, class_id, classroom_id, semester, week_start, week_end, week_type, day_of_week, section_start, section_end。

这里有几个关键决策值得解释。

节次存储：不建议只存一个“第几节”，因为存在两节连排、三节连排的情况。我用section_start和section_end表示从第几节到第几节，例如 1-2 节、3-4 节。判断冲突时，只需要检查两个区间是否有交集即可。

周次存储：week_start和week_end表示课程从第几周到第几周，week_type表示是“全周”“单周”还是“双周”。在冲突检测里，单双周的情况需要额外处理：如果课 A 是全周 1-16 周、课 B 是双周 1-16 周，它们虽然周次范围重合，但实际并不会在同一周出现，所以不能直接算作冲突。

2.3 冲突检测 SQL 还是 Java 做？我的选择

排课冲突检测放哪一端是个常见的纠结点。用 SQL 的话，一句WHERE条件里写四五个AND，看着很猛，但一旦条件复杂，可读性差、调试困难，后期要扩展“临时调课”“学期替换”之类的功能会非常痛苦。所以我选择在 Java 层做检测，把规则写成一个独立方法：

public boolean isConflict(ScheduleRequest req) { // 同一班级同一时间不能有课 // 同一教师同一时间不能有课 // 同一教室同一时间不能有课 // 单双周需要额外判断 }

每个判断单独写清楚，再用单元测试把典型场景覆盖一遍：同班冲突、同教室冲突、同教师冲突、单双周不冲突、跨节次相邻但不重叠。这五个用例跑通，我的把握就大了很多。投 SQL 那一版我也试过，不是不能用，而是出了 bug 之后排查效率太低。

3. 后端实现：SpringBoot 接口设计的几个关键决策

后端的整体思路是 Controller 层只接收参数和返回统一结构体，Service 层放业务逻辑，Mapper 层做数据库操作。三层结构听上去像教科书，但真正落实到课表系统里，有几个点需要单独强调。

3.1 用 JPA 还是 MyBatis：哪种更适合这种系统

我的判断是：如果你的核心业务是排课冲突检测这种复杂查询，MyBatis 配 XML 更可控；如果你主要做标准 CRUD，Spring Data JPA 开发速度最快。这个项目我用的 MyBatis-Plus，理由有三：代码生成器能直接对着表生成实体和 Mapper，省去大量重复劳动；分页插件内置，列表查询写起来没有心智负担；LambdaQueryWrapper 对条件查询的写法非常友好，课表筛选、班级筛选这种多条件动态查询尤其方便。

不过有一点需要注意：MyBatis-Plus 默认的字段映射规则是驼峰转下划线，如果你数据库里手动建的表字段命名不统一（比如有的叫teacherName，有的叫teacher_name），运行起来会出现查不到数据的问题。所以从第一天起就统一约定：数据库字段一律小写加下划线，实体类字段一律驼峰，后面会省掉很多莫名其妙的查询。

3.2 统一返回体与全局异常：答辩时老师爱问的细节

接口返回我封装了一个Result<T>，包含code、message、data三个字段。代码简单，但作用很大：前端不管请求成功失败，都按同一个结构解析，不需要为每个接口单独写错误判断。全局异常处理用@RestControllerAdvice拦截业务异常和参数校验异常，返回对应的 code。

这里特意把“业务异常”和“系统异常”区分开。比如排课冲突，属于业务异常，返回 code 50001，前端弹窗提示“该时段教师已有课”；而空指针之类的属于系统异常，统一返回 500，前端只提示“服务器开小差了”。答辩时老师问到“你怎么处理异常的”，把这两层的区分讲清楚，就能体现出你对代码质量的把控。

3.3 权限控制：JWT 还是 Session

课表系统的权限其实很典型——管理员能调课、排课、管理基础数据，教师能查看自己名下的课表，学生只能查看本班课表。我用的是 JWT 方案：登录成功后生成一个 token，前端每次请求在请求头里带上，后端通过拦截器解析 token 并获取当前用户角色。

选择 JWT 的主要原因还是前后端分离的结构。后端接口是无状态的，前端可以是任意域名部署，不用考虑 Session 同步的问题。要注意的是，JWT 生成时不要放太多信息，放用户 ID、用户名、角色就够了，并且一定要设置过期时间。我把有效期设为 12 小时，前端每次请求回来后判断是否快过期，如果小于 2 小时就静默刷新一次，体验比固定在 30 分钟过期好很多。

3.4 接口设计清单：最常用的四类接口

把整个项目常用的接口整理成一张表，方便你在写论文画接口图的时候直接参考：

课表查询这个接口是最重要的，前端的周课表网格完全依赖它。我的实现方式是：后端把某个班级或教师的所有排课记录一次性查出来，在 Java 层组装成一个七日节次二维结构，再返回给前端。这个设计比前端拿到原始排课列表后再自己分组要稳定得多——前端只负责渲染，不负责业务处理，逻辑边界更清晰。

4. 前端实现：Vue 里的课表网格怎么画才不费劲

前端部分看着好像只是把数据展示出来，但课表组件这种网格型布局，如果没规划好，代码会写得很痛苦。我一开始踩过一个坑：直接用 HTML table 一个个<td>去拼，数据一变，DOM 全要重新渲染，页面卡顿不说，代码也乱成一团。

4.1 用二维数组驱动视图：课表渲染的思路

我从一开始就决定：前端不维护任何业务判断，只渲染后端给的数据结构。后端返回一个二维数组tableData，索引一维表示星期（周一至周日），索引二维表示节次（第 1 到第 12 节），每个单元格的值要么是一个课程对象，要么是空对象。

const tableData = [ // 星期一 [ {}, { courseName: '高等数学', teacherName: '张老师', location: 'A-101' }, ... ], // 星期二 ... ]

前端做的事情就变得异常简单：渲染一个 12 行的表格，每行一个节次，每列一个星期，循环取出tableData[day][section]，有值就展示课程卡片，没值就留空。课程卡片里放课程名称、教师、教室，点击卡片还能弹窗查看详情。数据一变，整个网格重新render一遍，框架的响应式机制会自行处理 DOM diff，完全不需要手工操作节点。

4.2 课程卡片颜色与视图样式

每个课程卡片可以加一个类型标签，比如必修课用蓝色、选修课用绿色、实训课用橙色。标签颜色在数据库课程表里用一个courseType字段存储，前端做一次映射，不需要写死。这种小细节在演示时非常显眼，老师一眼就能看出系统对不同课程类型做了区分，而不是所有内容堆在一起。

卡片内部建议用两行或三行布局：第一行课程名，第二行教师和教室，第三行周次区间。如果节次跨度不止一节课（比如 1-2 节连排），单元格要能正确展示课程从第 1 节到第 2 节。我实现的方案是表格单元格做rowspan，但在 Vue 里处理rowspan很麻烦，后来直接改成了“每个节次独立一行，连排课程在两个节次行里都显示”，虽然样式上没有合并单元格那么好看，但胜在代码简单、逻辑不容易出错。如果你对合并单元格有执念，我的建议是放到后期优化阶段再处理，第一版先把功能跑通。

4.3 前端权限与路由守卫

Vue 侧的路由守卫要做的事很简单：没有 token 的人不能进主页，管理员和教师、学生的菜单列表不一样。我用router.beforeEach做拦截，在路由 meta 里配置roles，登录用户的角色不在数组里就直接跳回首页。菜单则根据角色返回的数组动态渲染，管理员显示“排课管理”“基础数据管理”“教师管理”，教师显示“我的课表”，学生显示“班级课表”。

这里有个值得提醒的细节：路由守卫只能控制页面能不能打开，后端接口权限仍然要在后端做校验。否则别人构造一个请求照样能调管理接口。我在后端的拦截器里对/api/schedule/**这类路径做了角色限制，管理员角色才允许访问，其他角色直接返回 403。

5. 部署与验证：从“本地能跑”到“演示不翻车”

很多毕设死在这一步——代码写完了，本地运行很正常，一到答辩演示就连不上数据库，或者前端页面白屏。部署环节看着不起眼，反而成了翻车高发区。

5.1 本地部署三步走

第一，导入数据库。用 Navicat 或者命令行执行项目里的init.sql脚本，把库和表建好，再检查一下application.yml里的数据库用户名、密码、端口是否和本地一致。第二，启动后端。直接mvn spring-boot:run或者打包成 jar 再java -jar，看到日志里出现“Tomcat started on port(s): 8080”就算成功。第三，启动前端。进入前端目录执行npm install，再npm run serve，浏览器打开 8081 端口，能跳转到登录页就说明前后端通了一半。

如果登录时接口报错，优先去看浏览器 F12 控制台里请求的具体报错信息。检查方向通常是：后端没启动、端口被占用、跨域配置问题、token 没传。这四个原因占据了 80% 的联调失败场景。

5.2 跨域配置：前后端分离最容易踩的坑

前端跑在 8081，后端跑在 8080，两者端口不一致，浏览器的同源策略会拦截请求。解决方案是后端加一个跨域配置类，允许http://localhost:8081访问。我在代码里用的是自定义的WebMvcConfigurer，重写addCorsMappings，允许所有来源（开发环境），但把allowCredentials设为 true，方便携带 token。

生产环境如果前后端部署在同一个域名下，比如 Nginx 把/api反向代理到后端的 8080，前端静态页面由 Nginx 直接分发，就不需要配置跨域了。这一点在部署文档里记得写清楚，很多人生产环境报错就是因为开了跨域又同时用 Nginx 代理，结果出现重复 header。

5.3 答辩演示的黄金数据准备

演示环节最怕的不是功能没写完，而是演示数据太寒碜——课表里稀稀拉拉几门课，看不出系统能力。我建议提前准备一组“有戏剧性”的数据：

一个班级的课表尽量填满到每天 6-8 节，让网格看起来饱满；同时造一两条冲突的排课记录（在后台故意添加一个冲突课，让系统弹窗提示错误），演示时主动展示“冲突检测”这个亮点功能；再准备一个教师的周课表，展示“按教师视角查看”的能力；最后进入教室管理页面，给某个教室勾选“停用”，立刻去排课页面尝试用这个教室排课，系统直接拒绝——这种前后呼应的演示，比口头解释“我有冲突检测功能”有力得多。

5.4 Nginx 部署与 jar 包发布

最后给出一个最简生产部署策略。前端执行npm run build生成dist目录，丢到 Nginx 的 html 目录下；后端执行mvn package得到 jar 包，复制到服务器上创建启动脚本；MySQL 导入数据库脚本，修改后端配置文件里的数据库连接为服务器地址。Nginx 配置里加一个 location 代理规则，把/api开头的请求转发到http://127.0.0.1:8080。这样整个系统就能通过一个 80 端口对外提供服务，访问体验和本地开发时完全一致。

有一点经验想分享：服务器上跑 jar 包，千万不要用java -jar xxx.jar直接挂在前台，一旦关闭控制台进程就断了。写一个nohup java -jar xxx.jar > run.log 2>&1 &的启动脚本，日志输出到文件里。排查问题看run.log，比对着控制台抓瞎强一百倍。

6. 论文写作与答辩：系统实现之外的另一半战场

论文不是代码的说明书，而是对你“发现问题-分析问题-解决问题”过程的完整呈现。我见过不少代码写得不错、论文却写得像流水账的例子，结果是答辩时老师只问了两句论文里的内容就卡住了。

6.1 论文结构建议：从“做了什么”到“为什么这么设计”

我的论文目录排布直接对应实际开发过程：绪论部分解释选题背景和国内外现状，要引用一定数量的文献，但不要从网上随便找几篇就拆进去，至少精读两三篇与“排课系统”“课程管理”相关的论文，提炼出“已有系统的问题——多数排课仍然手工处理、缺乏冲突检测机制”这类核心观点；需求分析部分画用例图，管理员、教师、学生三个角色各一张，把核心业务流程写清楚；系统设计部分给出整体架构图、功能模块图、数据库 ER 图；系统实现部分按“基础数据管理”“排课管理”“课表查询”“统计展示”四个功能模块逐个讲解，每个模块配合核心代码片段和界面截图；系统测试部分写测试用例表，覆盖正常流程、异常流程、边界条件，乙方把“同教室冲突排课被阻止”这类用例明确写进去，答辩时非常有说服力。

6.2 答辩预演：最可能被追问的五个问题

提前把这些问题想清楚，答辩现场会稳很多：

为什么选这个课题？从“高校课表管理仍然依赖 Excel 手工排课，容易出错且效率低”这个实际痛点切入，再延伸到你做的系统的价值。

排课冲突检测是怎么实现的？讲清楚五个维度的校验逻辑，最好现场打开代码或者数据库演示一个冲突场景。

如何防止一个教师同时被安排两门课？直接回答后端在新增排课时执行教师时间段交集判断，并现场展示重复提交失败的效果。

如果业务量变大了，系统怎么优化？从三个角度回答：数据库索引优化、后端接口缓存、前端数据分页。不用展开太深，体现你有扩展性思考即可。

你在项目里遇到的最大困难是什么？这是个送分题，但很多人答成“时间不够”“熬夜太多”。正确的回答方式，是讲一个具体技术问题的解决过程——比如单双周冲突检测的边界处理、JWT 过期刷新机制的设计，既能展示能力又有故事性。

6.3 这部分我踩过的坑

最典型的坑是论文写完了才发现系统和论文内容对不上。比如论文里写了“支持教室容量与合班人数校验”，但代码里根本没实现；又或者系统实现了“教师工作量统计”，论文里却只字未提。我每次都会在动手写论文章节之前，先把这个模块的代码清单和实现截图备齐，再动笔。代码截图、数据库截图、界面截图一样都不能少，这些素材在写论文时就是炮弹，没有的话临时补截图会被看出破绽。

7. 写在最后：给想直接“借鉴”源码的同学提个醒

如果你手头的项目是一个现成的课表系统源码，我的核心建议是：不要整包拿来就交，至少要重新梳理一遍表结构、改掉所有硬编码的学校信息、把前后端联调跑通，并至少完成一个属于你自己的增强功能。哪怕只是加一个“Excel 导入课程”的功能，或者给课表页面加一个“打印”的样式，都能在答辩时讲出一个完整的故事——“这是我在原有系统基础上做的二次开发”，远比拿着一套完全陌生、一问三不知的源码强。

我个人的习惯是，拿到一套不熟悉的系统后，先把手动测试的用例抄在纸上，一条一条跑，每跑通一条就勾一条。不是为了验收系统有没有问题，而是为了在跑的过程中把系统的每个角落摸一遍，这样答辩时无论老师点哪块功能，我都不至于愣住。那本写满用例的备忘录，往往比电脑里的项目代码更有安全感。