很多人拿到“Java Web 课表管理系统源码”这种毕业设计项目第一反应就是先跑起来、改个学校名、改个LOGO然后等着答辩。说实话这个项目确实被高估了也被低估了。高估的是以为排课功能就是简单的增删改查低估的是课表里那一堆看不见的时间片冲突、单双周逻辑、教室复用规则能在期末周把你心态直接搞崩。但换个角度看课表管理系统恰恰是全栈练手的好题材——后端有典型的RBAC权限模型前端有复杂的表格渲染业务数据库还有经典的多对多关系校验场景刚好能把SpringBoot2、Vue3、MyBatis-Plus、MySQL8.0这套技术栈串起来用一遍。这篇文章我就围绕这套课表管理系统从数据库设计讲到前端周视图渲染再讲MySQL8.0部署和项目文档怎么写。不是教你怎么把源码跑起来交差而是帮你看懂这个项目的每一块肉是怎么长的以及哪些地方是你答辩时最容易被追问的。1. 业务边界动键盘之前先把三件事想清楚很多做毕设的同学打开IDE就建表这其实是大忌。课表系统表面上是“课程表管理”但它内部牵涉的业务规则非常多。如果一开始不把业务边界画清楚后面代码写一半就会开始缝缝补补。1.1 三个前置问题排课粒度、系统角色、数据来源第一个问题是排课的最小单位。课表不能只排到“星期一”你得排到“第几周的星期几的第几节”。比如“第3周到第16周每周一第1、2节”和“第6周周三第5节”是两种完全不同的粒度。很多半成品源码把时间片只做到“星期节次”不支持指定周次结果期末课表一生成实验课和理论课全部撞车。第二个问题是系统里到底有哪几类人。课表系统通常有管理员、教师、学生三个角色管理员负责维护基础数据和排课教师查看自己的课表学生查看班级课表。有些学校还多一个教务审核的角色。这个角色划分直接决定了菜单权限和接口设计比如学生端只能查询已发布的课表不能看到草稿状态的排课数据。第三个问题是数据从哪来。毕设如果只是手工录数据那还好办但真实场景里每学期课程数据都是从教务系统导出的批量导入才是刚需。如果你在做源码二开最好给排课表留一个批量导入的入口哪怕只是Excel解析也能让项目完整度高一个档次。1.2 一张流程图看清核心业务链路课表系统的主流程其实很清晰可以用一张流程串起来理解管理员维护基础数据教师、班级、课程、教室管理员选择课程指定授课教师、上课班级、时间片、教室系统做冲突校验同教师、同班级、同教室不能在同一时间片内占用校验通过后保存为草稿状态管理员手动发布状态变为已发布教师端和学生端各自查询对应维度的课表这个过程看起来不复杂但它决定了数据表的关系。我建议你拿到任何一份课表系统源码先别急着看Controller先按这个流程去对它的数据表设计马上就能看出这个项目是精心设计过的还是临时堆出来的。2. 数据库设计五张核心表如何撑起整套课表系统数据库设计是这个项目的灵魂。我见过太多课表系统源码课程表、教师表、班级表单独看都没问题一到排课表就露馅——要么缺周次字段要么没有状态字段要么直接用逗号分隔存多个教室。这里我以一套比较规范的建模方案为例讲讲核心字段该怎么设计。2.1 排课表的时间片模型是系统的心脏先看最关键的排课表schedule它应该包含这些字段字段类型说明idbigint主键course_idbigint课程IDteacher_idbigint教师IDclass_idbigint班级IDclassroom_idbigint教室IDsemestervarchar学期标识如“2025-2026-1”week_startint起始周week_endint结束周week_typetinyint周类型0不分单双周、1单周、2双周day_of_weektinyint星期几1到7period_startint开始节次period_endint结束节次statustinyint排课状态0草稿、1已发布这里有几个设计点要特别说一下。第一周次用week_start和week_end表示范围再用week_type细分单双周比单独存一个weeks字符串字段靠谱得多。字符串如“3,5,7,9,11”虽然灵活但做SQL查询和冲突校验时都要拆字符串性能差还容易写错。第二节次用数字而不是时间。比如period_start1表示第1节课period_end2表示连续上第1、2节。这样排课表不用关心每节课具体的上下课时间时间映射交给前端显示层去做。如果上午第1节是8:00-8:45那么前端拿到1-2节就知道是8:00-9:30逻辑非常干净。其他基础表的字段就比较常规了。课程表course有课程名称、学分、学时教师表teacher有教师姓名、工号、所属院系班级表classes有班级名称、年级、专业。这里要注意教师和学生要不要拆分账号体系。如果项目里同时有学生用户和教师用户登录建议单独建一张user表存账号密码再用user_type区分角色不要把教师姓名当登录名。2.2 冲突检测为什么不能全交给SQL硬扛排课系统最常见的需求是管理员排课时系统要能提示“该教室这个时间已被占用”或“该教师这个时间有课”。这个校验逻辑就是冲突检测。冲突有三维同一教室在同一时间片内只能有一门课同一教师在同一时间片内只能有一门课同一班级在同一时间片内只能有一门课你当然可以写SQL去查排课表里是否存在重叠记录但问题在于“重叠”不是简单的等值查询。新排的课是第3-16周周一第1-2节已有的课是第5-10周周一第1-2节这两条记录时间片不相等但确实冲突了。要判断两个周区间是否有交集SQL写起来会很绕。所以更稳的做法是在应用层写一个独立的冲突校验方法把两个时间片的重叠判断封装成方法复用。核心判断逻辑就是把两个区间比较函数组合起来周区间有交集newStart oldEnd newEnd oldStart星期相等dayOfWeek相同节次区间有交集newPeriodStart oldPeriodEnd newPeriodEnd oldPeriodStart周类型兼容新排的是单周已有的也是单周或不分单双周才算冲突我用MyBatis-Plus做查询时可以先用LambdaQueryWrapper把时间片可能重叠的记录捞出来再在Java里做上面的区间判断。这种方式虽然多查了几条记录但逻辑直白也方便批量导入时复用同一个校验方法。我在实际项目里是把校验逻辑放在ScheduleService里独立成一个checkConflict方法排课接口、批量导入接口都调它非常好用。3. 后端SpringBoot2 MyBatis-Plus落地通用CRUD服务怎么搭后端这块SpringBoot2是骨架MyBatis-Plus是利器。很多拿到的源码会用MyBatis-Plus的BaseMapper和IService但你得知道这套东西到底解决了什么问题不然答辩被问到就露馅。3.1 为什么选MyBatis-Plus而不是JPA或手写MyBatis先说结论对于课表管理系统这种以单表CRUD为主、关联查询为辅的业务MyBatis-Plus是效率最高的选择。JPA虽然写起来优雅但多表关联和复杂查询时它的懒加载和N1问题够你调半天手写MyBatis XML每个实体都要写insert、update、selectById、分页重复劳动太多。MyBatis-Plus恰好卡在中间单表CRUD由框架帮你生成多表复杂查询你还是可以写XML灵活性和效率都有。具体到课表系统典型场景是学生查课表时需要关联查询课程名称和教师姓名。这种查询用MyBatis-Plus自带的LambdaQueryWrapper加嵌套查询就能解决比如先按class_id查出schedule列表再用course_id集合去查课程表最后在内存里组装。数据量不大时完全够用还避免了写复杂的JOIN SQL。3.2 通用CRUD服务的实现套路MyBatis-Plus提供了一对黄金组合IServiceT接口和ServiceImplM, T实现类。你的业务Service直接继承IServiceSchedule实现类继承ServiceImplScheduleMapper, Schedule然后你就拥有了save、removeById、page、list、lambdaQuery这一整套通用能力。示意代码大概是这样的public interface ScheduleService extends IServiceSchedule { void checkConflict(Schedule schedule); PageSchedule pageSchedule(PageDTO dto); } Service public class ScheduleServiceImpl extends ServiceImplScheduleMapper, Schedule implements ScheduleService { Override public void checkConflict(Schedule schedule) { // 冲突校验逻辑 } }这里有一个值得在答辩时讲的点MyBatis-Plus的通用CRUD服务是“无状态”的。所谓无状态就是Service里不持有用户会话信息每次请求通过JWT解析出当前用户ID后显式传给Service层做数据过滤。这种设计让Service可以复用也方便做单元测试——你不需要mock一个session上下文构造一个实体对象就能调用增删改查方法。3.3 三个必须配置的功能分页、自动填充、逻辑删除MyBatis-Plus有几个功能默认不生效必须配了才有效这里我按踩坑概率排序。第一个是分页插件。很多人写完page()方法发现分页不生效查出来全是全表数据就是因为没注册PaginationInnerInterceptor。在配置类里加一段Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; }分页插件不注册Page对象不会真的执行LIMIT语句这是MyBatis-Plus最常见的新手坑。第二个是字段自动填充。比如create_time、update_time这些字段每次插入更新都手动set太麻烦。可以给字段加TableField(fill FieldFill.INSERT)注解再实现MetaObjectHandler接口在insertFill和updateFill里统一处理。第三个是逻辑删除。课表系统的删除操作其实很敏感教师排好的课如果被物理删除出了问题很难追溯。建议在表里加deleted字段实体上加TableLogic注解这样调用removeById时执行的其实是UPDATE语句把deleted置为1。查询时MyBatis-Plus会自动追加deleted0条件数据不会真正消失。这一点在答辩时很加分因为体现了一个开发者对数据安全的理解。4. Vue3前端周课表视图组件从0到1的实现思路前端Vue3这部分项目通常会用Vite Vue3 Element Plus Pinia这套主流组合。课表管理系统的前端最核心的页面就是“周课表视图”也就是把一周的课程像真实课表那样渲染出来。这个组件很能体现前端功底我重点讲讲实现思路。4.1 项目骨架与目录分工用Vite创建项目后安装element-plus、vue-router、pinia结构上建议按模块划分而不是按文件类型划分views/admin管理员端课程管理、排课管理、教室管理views/teacher教师端我的课表views/student学生端班级课表components/schedule课表相关组件包括周课表、周次选择器apiaxios请求封装一个容易被忽视的点是路由守卫。登录后才能访问课表页面没有token就重定向到登录页。这个逻辑写在vue-router的beforeEach里面看似简单但很多半成品前端源码都没有导致页面刷新后直接跳到404。4.2 周课表组件网格布局与合并单元格算法周课表的渲染有两种常见方案一是用Element Plus的el-table改造二是用CSS Grid自己画。我更推荐CSS Grid因为课表本质上是一个二维网格列是周一到周日行是节次。核心数据结构是二维数组grid[day][period]day取值范围0到6period取值范围1到最大节次。渲染时遍历这个数组遇到课程对象就填充颜色卡片。但这里有个细节大学课程经常一次占用两节比如第1、2节连上。如果按每行一个节次渲染会出现课程只占半截的问题。解决方法是合并单元格思路是“只有课程的开始节次才渲染单元格”。我当时的处理逻辑是把schedule数据按dayOfWeek分组每个分组里按periodStart排序遍历grid[day][period]时如果当前位置的课程对象存在且period schedule.periodStart才渲染这个课程卡片并设置rowspan periodEnd - periodStart 1如果当前位置有课程但period periodStart说明该行被上面的课程卡片合并覆盖了直接跳过这个算法说起来简单但初次写容易漏掉“跳过被合并行”的逻辑。我见过不少代码渲染出来的课表连上两节的课程会重复显示两次。另外课程卡片建议用不同背景色区分课程类型比如理论课蓝色、实验课橙色、体育课绿色视觉上会清晰很多。4.3 联调中的跨域与时间格式化问题前端联调时最容易炸的两个点第一个是跨域。Vite开发服务器默认跑在5173端口后端跑在8080端口直接请求就是跨域。解决办法是在vite.config.js里配置代理server: { proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } }前端所有请求都走/api前缀后端接口统一加/api前缀这样开发和部署都不需要处理CORS的麻烦。第二个是日期时间格式化。MySQL8.0和Java后端配合时LocalDateTime字段默认序列化成2025-01-06T10:15:30这种T格式。Vue3前端直接用的话页面上会出现一个尴尬的字母T。建议后端做一个统一的Jackson配置把LocalDateTime格式化成yyyy-MM-dd HH:mm:ss全局生效省得前端每个字段都调dayjs去解析。5. MySQL8.0环境准备三个最容易翻车的配置用MySQL8.0做这个课表系统环境配置上有三个经典坑每一个都能让你白折腾两小时。我在重新搭这套环境时全都踩过提前给你排掉。5.1 时区设置连接串必须写清楚MySQL8.0和旧版本最大的不同之一就是时区处理。如果你用默认连接串jdbc:mysql://localhost:3306/course_schedule去连很可能会报一个“The server time zone value CST is unrecognized”的错误。这是因为MySQL8.0驱动对时区要求更严格而系统默认时区是CST驱动不知道CST到底代表中国标准时间还是美国中部时间。解决办法就是在JDBC连接串里明确指定时区我用的完整连接串是jdbc:mysql://localhost:3306/course_schedule?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalseallowPublicKeyRetrievaltrueserverTimezoneAsia/Shanghai解决了时区问题allowPublicKeyRetrievaltrue解决MySQL8.0默认加密认证的兼容问题下面会细说。5.2 认证插件与驱动版本MySQL8.0默认的账号认证插件是caching_sha2_password而老版本的JDBC驱动5.x系列不支持这个插件。如果你用旧驱动连MySQL8.0会报错Public Key Retrieval is not allowed这个问题的解法有两个推荐的是把驱动升级到mysql-connector-j8.0.x及以上版本然后在连接串加上allowPublicKeyRetrievaltrue。不推荐的方式是执行SQL把账号插件改回mysql_native_password虽然能用但属于绕路方案换一个环境又要踩一遍。如果你是拿Docker装MySQL8.0命令大致是这样docker run -d \ --name mysql8 \ -p 3306:3306 \ -e MYSQL_ROOT_PASSWORD123456 \ -e MYSQL_DATABASEcourse_schedule \ mysql:8.0注意一定要指定mysql:8.0而不是mysql:latest否则哪天官方把latest变成9.0你的项目可能就因为认证方式变化而连不上了。版本锁定是Docker使用的基本素养。5.3 字符集utf8mb4才是正确选择MySQL8.0的默认字符集其实已经是utf8mb4了但如果你是从旧版本迁移过来的数据库或者手工建库还是建议显式指定一次。课表系统里会有课程名称、教师姓名这些中文数据如果字符集不对轻则中文乱码重则插入报错。建库语句CREATE DATABASE course_schedule DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;另外数据库连接串里的characterEncodingutf8和数据库的utf8mb4是两个层面的东西一个管客户端传输一个管存储两个都要对才能保证中文不出问题。6. 权限与课表发布让系统向真实产品靠拢课表系统如果只是把增删改查做出来那和普通的图书管理系统没区别。真正让它贴近真实业务的是两件事一是不同角色只能看到自己的数据二是排课草稿不能直接暴露给学生。这两块做出来答辩时老师会觉得你有产品思维。6.1 轻量JWT方案代替重型的Spring SecuritySpring Security功能强大但配置繁琐对毕设项目来说有点“杀鸡用牛刀”。我更推荐用JWT HandlerInterceptor做一个轻量的登录鉴权方案逻辑清晰面试也好讲。实现要点是用户登录成功后后端生成一个JWT字符串里面放入userId和userType前端把token存到localStorageaxios请求拦截器在每次请求时把token放到Authorization头里后端写一个AuthInterceptor拦截所有/api/**请求解析token并放入ThreadLocal在Controller里写一个注解或者直接从ThreadLocal取userId查询时按userId过滤数据教师查课表时先从token解析出教师ID然后只查这个教师的排课记录学生查课表时先从班级维度过滤。这样即使有人猜到接口地址也不容易越权查到别人的数据。6.2 草稿与发布状态机很多课表系统源码都有个问题管理员排完课学生端立刻能看到。这在真实场景里是不合理的因为排课往往需要几天时间中途会不断调整学生看到半成品课表会引起不满。我的做法是在排课表增加status字段0表示草稿1表示已发布。管理员排课时状态是草稿只有管理员手动点击“发布”后学生端和教师端的查询接口才返回已发布的数据。教师端可以放宽一点允许看到与自己相关的草稿学生端严格一点只查已发布。这个状态机不复杂一个字段加一个查询条件就能实现但对系统完整度的提升非常大。7. 打包部署与配套文档项目能跑起来只是起点课表系统到了交付阶段最后两步是部署和文档。很多半成品源码这两块做得很差要么只有一个启动说明要么压根没有说明。但这两件事恰恰是答辩展示和后续维护的关键。7.1 前后端打包与Nginx反向代理后端打包很简单在项目根目录执行mvn clean package -DskipTests生成的jar放在target目录用java -jar就能启动。如果你在本地联调时用的application-dev.yml部署时建议用application-prod.yml切换数据库和端口配置SpringBoot用--spring.profiles.activeprod指定。前端打包执行npm run build生成dist目录。生产环境我推荐用Nginx托管前端文件同时把/api路径反向代理到后端端口这样前后端都部署在80端口不会暴露后端8080端口。一个简化版的Nginx配置server { listen 80; server_name your-domain.com; location / { root /var/www/course-schedule/dist; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }注意try_files $uri $uri/ /index.html这一行Vue3路由如果使用history模式刷新页面时如果没有这个配置会404。这是前端部署最常见的坑。7.2 项目文档应该怎么写才有含金量既然标题写了“含文档”那这个文档就不能只是把源码贴上去。我写项目文档的经验是按“新人从零启动项目”的视角来组织让一个没见过这个项目的人照着文档能一步步跑起来。一份合格的课表系统文档至少包含五块内容环境要求JDK版本、Maven版本、Node版本、MySQL版本全部写清楚初始化步骤创建数据库、执行SQL脚本、修改配置文件、启动后端、启动前端接口说明核心接口的请求方式、路径、参数、返回结果不必覆盖全部但登录、排课、课表查询这些核心接口一定要写业务规则说明排课冲突检测规则、草稿发布机制、构建脚本常见问题时区报错、端口占用、前端跨域我个人的习惯是文档里放一张表列出“常见启动错误”和“对应解决方案”比如MySQL连接串没写serverTimezone会报什么错Nginx没有try_files刷新页面为什么404。这种文档在你是新手时救了你你把它整理出来答辩和日后再看都会非常省心。在整个课表系统的开发过程中我最深的体会是业务模型一定要在数据表设计阶段定型。你可以用任何框架但时间片、状态机、冲突规则这些东西如果建表时没想清楚后面改起来成本极高。我最初拿到一些半成品源码时第一件事不是跑通它而是画清楚角色关系和排课模型这一步直接决定了后面所有代码是“拼凑”还是“生长”。如果你也在折腾类似的课表项目建议先拿一张纸把排课时间片写出来理清一周的节次和课表网格的对应关系再打开IDE你会发现很多代码其实是在帮你实现你已经想明白的那张纸。