一次Java Web实训项目的完整拆解：SpringBoot2+Vue3课表管理系统

近几年高校实训、毕设里Java Web项目有个挺明显的变化：SSH那套旧东西基本退出舞台了，SpringBoot成了默认起点，前端也不再是JSP或者简单的jQuery拼页面，而是整体切到Vue3 + Element Plus这类前后端分离方案。我最近帮某高校整理了一套课表管理系统的源码，技术栈是SpringBoot2 + Vue3 + MyBatis-Plus + MySQL8.0，标题里虽然没有明确的“实训”两个字，但看它带文档、带完整源码、连数据库版本都锁死，基本可以断定这又是一套典型的Java Web实训/毕设项目。

这篇文章，我就基于这个项目标题，把这类课表管理系统从立项到落地的前前后后拆开讲讲。内容包括：为什么这套技术栈是当前的主流配置、数据库表怎么设计才抗折腾、老牌框架MyBatis-Plus如何帮你少写一半CRUD、前端权限和排课逻辑怎么落地、以及跑起来之后最容易踩的坑。这不仅是给正在做类似项目的人参考，也会聊聊我在实际改这套代码过程中的一些体会。

如果你是正在准备Java Web课程设计的学生，或者想拿SpringBoot做一套带前端、带权限、带业务逻辑的完整项目来填充简历的开发者，这篇内容应该能让你少走不少弯路。

1. 这个项目的“新”到底新在哪：SpringBoot2 + Vue3搭配逻辑

先别急着看代码，我们得先搞明白一件事：为什么现在的课表管理系统不约而同选择SpringBoot2 + Vue3这套组合？它到底比老方案强在哪？

1.1 后端选SpringBoot2而不是SpringBoot3的考量

首先聊聊SpringBoot版本。这里的SpringBoot2，具体一般是2.7.x。有人会问，SpringBoot3都已经出了，为什么还要用SpringBoot2？原因很实在：大量教学资源、开源组件、培训资料还是以SpringBoot2为主，生态成熟度高。尤其国内很多高校的实训环境里，JDK还停留在8或者11，SpringBoot3强制要求JDK17以上，光这一个条件就能劝退一批机房环境的用户。

所以SpringBoot2不是“旧”，而是稳。2.7.x这一代基本把自动配置、Starter机制、Actuator健康检查这些核心能力都打磨到位了，配起来也很省心。在课表系统里，后端只需要提供纯RESTful接口，不掺模板引擎，SpringBoot2完全够用，性能和开发效率都有保障。

1.2 前端为何选Vue3而不是继续用Vue2

一般以后端技术为主的开发者，对Vue3的态度通常是“能用，但不想折腾”。但课表管理系统这类项目，页面上有大量表格、弹窗、表单校验、动态路由渲染，Vue3的组合式API（Composition API）明显比Vue2的选项式API更适合复杂交互。

写代码的感受差异很大：Vue2里想抽公共逻辑，要用mixin，项目一大，变量来源就成谜；Vue3直接用setup函数和自定义Hook，一个课表导入的公共逻辑抽出来就是一个函数，哪来的变量一目了然。而且Vue3的响应式基于Proxy，数组下标的修改、对象属性的新增删除都能被拦截，这比Vue2的 defineProperty 在边界情况下的表现舒服不少。

1.3 前后端分离给课表系统带来的实际好处

用这套组合不只是因为“看着高级”，它解决了一个很实际的维护问题：课表系统的角色差异很大。学生要查课表、教师要看自己的排课、教务要排课和调课，如果前后端耦合在一起，每次加个功能都要动一整条链路。拆开之后，后端专注业务规则（比如排课冲突检测），前端专注交互体验（比如课表表格的拖拽换课），改动边界清晰多了。

配套的还有Axios做HTTP请求、Pinia或Vuex做全局状态、Element Plus做UI组件库、Vite做构建工具。项目标题里虽然只提了Vue3，但你要知道，一套真正能跑的Vue3前端，背后一定是这套配套体系。

2. 从课表系统需求出发：数据建模是比写代码更烧脑的环节

任何管理系统，数据库表设计都是灵魂。课表系统尤其如此，因为它的核心实体“开课记录”牵扯到多个维度：课程、教师、班级、教室、时间。这几个维度交叉起来，冲突检测就变成了一个典型的多维约束满足问题。

2.1 核心表结构：不只五张基础表

网上很多课程设计的课表系统，数据库就五张表：用户表、学生表、教师表、课程表、课表。这种设计应付简单的展示还行，一旦涉及到排课冲突检测、教室占用校验，五张表根本撑不起来。

我建议的改造方案是拆成分层设计：

• 基础信息层：用户表（包含角色字段）、学生表、教师表、教室表、课程表
• 业务关联层：班级表、开课记录表（课程+教师+班级的绑定关系）
• 课表层：课表项表（开课记录+教室+时间段+周次）

其中最容易忽略的是周次字段。很多课表系统的数据表里只存了星期几和第几节，结果遇到单双周课程就傻眼了。实际排课里，一门课很可能只在第2周、第4周、第6周上，而不是每周都上。所以最合理的做法是把上课的周次编码成一个字符串，比如“1-16周”存成“1-16”，单周课存成“1,3,5,7,9,11,13,15”，校验冲突的时候直接拿周次编码做计算。

2.2 一个容易被忽略的点：时间戳还是时间字符串

课表项里时间怎么存？有人用beginTime和endTime存时间戳，有人用weekday和section存星期几和节次。在课表这个场景里，我强烈建议用枚举编码的方式，而不是时间戳。

举个例子：星期一第三大节，存成 weekday=1, section=3，语义明确，校验冲突也好写。如果存时间戳，还得把时间戳转换成星期几和节次，凭空多一层计算，而且还可能因为时区问题闹出乌龙。可以把节次映射表单独维护一张字典表，里面有该学校上午、下午、晚自习具体的起止时间，课表项只存节次的编号，到时候做UI展示再映射。

2.3 教室冲突检测：SQL思维还是应用层思维

排课冲突主要包括三种：教师冲突（同一老师同一时间不能上两门课）、班级冲突（同一班级同一时间不能上两门课）、教室冲突（同一教室同一时间不能同时被两门课占用）。如果写一个checkConflict接口，最直接的方案是先查目标时间段哪些课表项已经在运行，再做应用层判断。

SQL写法大致是这样：

SELECT * FROM schedule_item WHERE classroom_id = 1 AND weekday = 3 AND NOT (end_section < 2 OR start_section > 4) AND (week_range rlike '...')

不过等你真正写代码的时候，课程和班级的绑定关系通常比较复杂，我见过的大多数实现最终还是回到应用层，用Java代码先查出来再遍历判断。数据库层面只做第一层粗筛，精度靠代码保证。不能说SQL方案不行，但对于大多数实训项目，应用层判断的代码更直观、更容易被答辩老师理解。

3. MyBatis-Plus加持下的后端CRUD：代码量锐减，但边界要清晰

说完了表结构，看后端代码怎么组织。现在的SpringBoot项目里MyBatis-Plus几乎是标配，不是因为它多么黑科技，而是因为它能帮你把初级CRUD的活儿全包了，让你把精力留在真正有业务逻辑的地方。

3.1 明显效率提升：BaseMapper和ServiceImpl

MyBatis-Plus最有价值的组件是BaseMapper<T>和ServiceImpl<M, T>。你的CourseMapper接口只要继承BaseMapper<Course>，就有了insert、deleteById、selectById、updateById这些基础方法。Service层同理，继承ServiceImpl之后，save、updateById、list、page全都现成。

写课表系统的课程管理模块时，我基本不用写一行SQL。Controller里的代码就是接收参数、调Service、返回结果。这样做的意义不只是“偷懒”，而是统一了接口风格。所有列表接口都会返回R<T>这种统一响应体，里面包含code、msg、data三个字段，前端拿到之后处理逻辑非常统一。

3.2 条件构造器：queryWrapper的正确姿势

MyBatis-Plus里最常用的类是LambdaQueryWrapper。它解决了一个很尴尬的问题：以前写MyBatis的Mapper XML，一个按课程名搜索的接口就得写一段动态SQL判断，字段多起来，XML里全是<if>标签。用LambdaQueryWrapper之后，代码变成了这样：

LambdaQueryWrapper<Course> wrapper = Wrappers.lambdaQuery(); wrapper.like(StringUtils.isNotBlank(name), Course::getName, name) .eq(courseType != null, Course::getType, courseType) .orderByDesc(Course::getCreateTime);

这里的好处很明显：条件不成立的时候，方法自动忽略这个条件，就不用自己拼SQL了。注意第一参数condition是布尔值，这个设计比直接拼接硬编码强得多，只是很多人没看文档就直接上手，然后发现条件无效，还得回来排查。

3.3 强推荐的代码生成器：懒人的艺术

这类项目的表往往有七八张，手写实体类和Mapper简直是浪费生命。我的做法是在项目根目录放一个代码生成器类，基于MyBatis-Plus的AutoGenerator，配置好数据源、包名、模板路径，运行一次，所有实体类、Mapper接口、Service接口、ServiceImpl实现类全部生成完毕。

生成的实体类字段上带@TableName和@TableId注解，表字段用下划线命名，实体属性用驼峰命名的映射也不用管，全局配置里开一个map-underscore-to-camel-case: true就全搞定了。

3.4 分页插件的坑：不配置就全量查询

MyBatis-Plus的分页并不是引入依赖就自动生效的，需要配置一个分页拦截器：

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

这是我见过最容易踩的坑：有人引入分页插件后发现page返回的 total 总是0，页面数据也分不动。原因很简单，就是没注册拦截器。这个配置常常被忽略，因为Spring Boot自动配置的锅太大，很多人以为引入starter就万事大吉，实际上分页这种通用能力还是得手动注册。

4. 课表页面的前端实现：Vue3下的组件化设计

后端接口准备好了，接下来看前端怎么把课表“画”出来。这也是这个项目里最有看头的部分，因为这毕竟不是普通的表格CRUD，有表格合并、周次切换、时间轴表头这些交互。

4.1 课表组件的数据结构设计

前端渲染课表，最忌讳的是按后端返回的嵌套结构直接渲染，那种代码通常是又长又绕。我习惯先把数据转换成一个前端专用的二维映射结构：

const gridData = ref({}) // gridData[weekday][section] = scheduleItem

这样用Vue模板渲染的时候，就是双层循环遍历，取到gridData[1][2]就直接是周一的第二大节那门课。数据转换放在前端拿接口数据的时候做，后端的返回结构保持规范，前端拿到再适配，这种职责划分最清晰。

4.2 Element Plus表格与自定义卡片的取舍

展示课表用Element Plus的el-table可以做到，但说实话，真正的课表更接近一个个小卡片，合并单元格处理起来非常痛苦。我见过聪明的做法是直接用div+ CSS Grid布局，星期几和节次作为两个维度，然后循环动态生成格子，每个格子根据课程颜色呈现不同背景。

<div class="schedule-grid" :style="{ gridTemplateColumns: '80px repeat(7, 1fr)' }"> <template v-for="weekday in 7" :key="weekday"> <template v-for="section in maxSection" :key="section"> <div class="schedule-cell" @click="cellClick(weekday, section)"> <!-- 渲染课程卡片 --> </div> </template> </template> </div>

用Grid布局还有个好处，之后加个调课功能，只要做单元格的拖拽事件（HTML5拖拽或vuedraggable），天生就适合课表那种可视化操作。

4.3 权限控制：路由守卫的双层把关

课表系统的前端权限，一般有两种做法：路由元信息控制按钮级权限，动态路由控制页面级权限。最简单可靠的方式是登录之后，后端返回当前用户角色，前端存到Pinia里，然后注册一个全局前置守卫：

router.beforeEach((to, from, next) => { const userStore = useUserStore() if (to.path !== '/login' && !userStore.token) { next('/login') } else if (to.meta.role && !to.meta.role.includes(userStore.role)) { next('/403') } else { next() } })

这套逻辑虽然简单，但应付实训项目已经足够。如果还想更专业一点，可以把动态路由做成后端返回路由表、前端router.addRoute动态添加，完整实现“不同登录人看到不同菜单”的效果。不过后者需要前后端配合做一套权限菜单表，很多同学做到一半就放弃了，我个人建议先做前端静态路由守卫，把整体流程跑通，有余力再升级。

5. 实测排错：把项目从启动到跑通的完整排查过程

趁这个机会也说点实际经验吧。标题里的这套系统我完整跑通过一遍，中间出了不少问题，有些是环境的，有些是代码层面的。这里挑几个典型说说。

5.1 MySQL8.0时区惹的祸

MySQL8.0刚装好的时候，URL里的serverTimezone没配或者配错，项目启动后查询就报The server time zone value 'Öйú±ê׼ʱ¼ä' is unrecognized这种错。解决方案是在JDBC URL后加serverTimezone=Asia/Shanghai&useSSL=false&allowPublicKeyRetrieval=true，注意是用&不是&，后者是XML转义写法，在YML配置里直接写一个&就好。

这个问题属于典型的“本地跑不起来90%是环境问题”案例，但每次都有人卡住。你可以先按顺序检查：JDK版本是不是8或11、MySQL版本是不是8.0.x、项目里的数据库URL用户密码对不对、SQL脚本有没有按顺序导入、前端npm install有没有装全。

5.2 前后端联调时最常遇到的跨域错误

SpringBoot后端默认只允许同源请求，前端跑在Vite的localhost:5173，后端跑在localhost:8080，一联调就报CORS错误。最简单的解决办法是后端写一个CORS配置类或者直接在Controller上加@CrossOrigin。

推荐统一配置类：

@Configuration public class CorsConfig { @Bean public CorsFilter corsFilter() { CorsConfiguration config = new CorsConfiguration(); config.addAllowedOriginPattern("*"); config.addAllowedHeader("*"); config.addAllowedMethod("*"); config.setAllowCredentials(true); UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource(); source.registerCorsConfiguration("/**", config); return new CorsFilter(source); } }

前端也可以用Vite代理解决跨域，后端不用动。Vite配置里加个proxy转发，把/api前缀的请求转发到http://localhost:8080，调试起来更舒服，但部署到生产环境还是得靠后端CORS支持。

5.3 数据权限和模型设计不匹配的坑

还有一个常见的逻辑问题：课表里学生只能看到自己的课，教师只能看到自己的课，教务能看到全部。但很多项目的schedule_item表压根没有存用户关联字段，导致做数据隔离的时候只能通过联查。

如果直接在课表项里加一个student_ids字段存JSON数组，看着方便，实际上破坏了表的范式，查询极难优化。正确做法是通过“开课记录”这个中间表关联：课表项→开课记录→学生选课关系，再去查学生。这样每个学生看到的课表，就等价于先查出自己选了哪些开课记录，再找这些开课记录对应的课表项。前端拿到的数据虽然需要几次联查，但逻辑清晰，答辩时也解释得通。

5.4 文档、注释和命名规范

标题里写了“含文档”，这类项目交付时文档基本包含：需求规格说明书、数据库设计说明、接口文档、使用手册。

我自己整理代码时有个习惯：每个Controller类上都加一段简短的注释，说明这个类是干什么的、主要对外提供哪些接口。每个接口方法上面，除了Swagger注解（如果有），至少写上入参和返回值的含义。最关键的是文档里的数据库设计说明，一定要跟实际SQL脚本保持一致。很多项目文档写的是V1.0设计，数据库已经改了三轮，最后答辩老师照着文档看代码，一对不上就直接挂科。

我特别推荐用Swagger这种在线接口调试工具来生成接口文档，写完Controller加几个注解，启动项目之后浏览器访问http://localhost:8080/swagger-ui.html，所有接口和参数一目了然，还自带联调调试功能，比手写Word接口文档高效得多。

6. 项目组装与部署体验：从前到后一键跑通

关于部署这块，也得说句实话：课堂项目里90%的部署方式就是本地双开，后端IDEA里启动，前端VSCode里npm run dev。这种方式比较简单，自己开发的时候自然是这么干的。但如果拿出去展示、或者交到别人手上，最好还是做一套可持续部署的配置。

6.1 后端打包部署的常规流程

SpringBoot自带内嵌Tomcat，所以打包成一个可执行jar不是问题。在pom.xml里配置好SpringBoot的maven插件之后，执行mvn clean package，就能在target目录下拿到一个一二百兆的jar包。

部署只需要java -jar course-system.jar，然后注意配置文件里数据库连接、Redis等相关参数。如果用Docker部署，写一个简单的Dockerfile：

FROM openjdk:8-jre-alpine COPY course-system.jar app.jar EXPOSE 8080 ENTRYPOINT ["java", "-jar", "/app.jar"]

不过多啰嗦一句：如果的服务器内存只有512MB，Docker部署再加个MySQL会有压力。这时候就要考虑把MySQL放在宿主机，只容器化运行jar包，或者干脆用宝塔面板这类工具直接运行jar包，省事很多。

6.2 前端打包后的Nginx配置

Vue3项目的打包流程就三个命令：npm install、npm run build、把dist目录放到Nginx的html目录下。Nginx需要做一件事：把/api路径反向代理到后端地址，同时处理history模式路由的fallback，否则刷新页面直接404。

server { listen 80; server_name localhost; root /usr/share/nginx/html; index index.html; location /api/ { proxy_pass http://localhost:8080/api/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } location / { try_files $uri $uri/ /index.html; } }

这个配置用了Vue Router的createWebHistory()就必须要配。图省事的话可以直接用createWebHashHistory()，URL会带个#，刷新不404，但看着不专业、对SEO不友好。我的建议是直接上history模式 + Nginx fallback，一次性到位。

6.3 运维里最不起眼的坑：数据库备份

最后再提醒一件最不起眼却最重要的事：数据库迁移。如果只把jar包拷到别的机器上，不把SQL脚本导入新数据库，项目根本跑不起来。所以源码包里一定有一份完整的course_system.sql，包含建库、建表、默认数据。默认数据尤其重要：至少要有一个初始管理员账号，不然系统启动后没人能登录，体验直接崩塌。

7. 我个人的整体评价：这套项目值不值得做、怎么做才加分

整套系统跑完一遍，我从做技术选型到最终交付的过程中，最大的感触是：这套方案把“主流”用得很稳，没有特别天马行空的技术炫技，但这恰恰是课设/毕设项目最需要的品质。

课表管理系统的核心不是技术难度有多高，而在于你的逻辑是否完整：排课冲突检测有没有覆盖教室、教师、班级三个维度；周次处理支不支持单双周；调课之后的记录是否可追溯。这些需求如果在数据库设计阶段就考虑到位，后期写代码会顺畅很多，答辩的时候也能向老师展示出你的思考深度。

如果你正打算做类似系统，我的个人建议是：先花两天时间好好设计数据表，再花一天时间把接口约定定清楚，最后再写代码。不要一上来就npm create vite然后把代码往上堆，做到一半发现表结构支撑不了业务逻辑，回头的代价远比你想象的大得多。

另外，文档这事真的别拖到最后。每做完一个模块就顺手截几张图、记几行说明，最后汇总成文档，比最后一天熬夜补齐要轻松，而且内容质量完全不是一个量级。