最近有朋友问我线上辅导班系统到底怎么做一个能交差、能演示、甚至能上线跑业务的版本，我直接把这套基于SpringBoot2+Vue3+MyBatis-Plus+MySQL8.0的源码从数据库表到接口逻辑完整对着梳理了一遍。说实话，现在做Java Web项目最幸福的事情就是技术栈可以选得很现代，同时又不会激进到给自己挖坑。SpringBoot2做后端底座，Vue3做前端交互，MyBatis-Plus管数据库CRUD，MySQL8.0当存储，这一套组合已经成了最近两年线上教育类、后台管理类项目的绝对主流搭配。尤其是标题里那句"含文档"，对于准备毕业答辩、课程设计交付的人来说，比代码本身还要救命——代码跑不起来可以修，文档逻辑不完整，答辩老师第一轮提问就能把你问穿。
所以这篇文章我不打算给你"贴一份源码然后说多好用"，而是把这套系统从需求拆解、技术选型、核心模块设计、启动部署、再到实操踩坑，整个环节掰开揉碎讲一遍。不管你是拿它当毕设，还是想在上面扩展功能做真实服务，都能找到直接能抄作业的部分。
1. 先拆需求：线上辅导班系统到底要解决哪些业务问题
很多同学拿到这类题目第一反应是"有课程表、有用户表、能登录、能下单就够了"。真这样做，做完你会发现系统既不像"辅导班"，也不像"线上产品"，更像一个散装CRUD demo。线上辅导班系统本质上是一套在线教育交易与学习管理平台，先搞清楚业务角色和业务链路，才知道表怎么建、接口怎么分。
1.1 用户角色与权限边界
系统的用户角色至少分三档：学生、讲师、系统管理员。如果你想把完整度拉开跟别人差距，可以再加一个教务/班主任角色，用来管理班级排课、查看学习进度、做学情统计。不过从绝大多数毕设和中小型项目的定位看，三角色做扎实，业务闭环已经能流转起来。
- 学生：注册登录、浏览课程、购买/报名课程、观看课程内容（章节视频或图文）、提交作业、发起提问。
- 讲师：管理自己名下课程、维护课程章节资料、批改作业、回复学生提问。
- 管理员：审核课程上下架、用户管理、课程分类管理、查看订单流水与销售统计。
这里有个最容易被人忽视的点：数据级权限。讲师只能看到自己名下的课程和提问，学生只能访问已报名课程的内容。前端隐藏按钮不算权限控制，真正的控制必须落到后端接口的查询条件里。比如讲师查询课程列表的SQL，必须强制带teacher_id = 当前登录用户id，而不是把全表数据查出后让前端过滤。
1.2 一条完整的业务链路
画业务链路图是我拿到项目需求后做的第一件事，比写代码重要得多。线上辅导班系统主链路可以概括为：
用户注册 → 浏览课程 → 选择课程 → 下单生成订单 → 支付/模拟支付 → 订单完成生成报名记录 → 开始学习章节 → 提交作业/提问 → 讲师批改/回复 → 学生查看反馈
这条链路里最关键的一步是订单与报名分离。新手最容易图省事，把购买课程做成直接往报名表里insert一条记录，导致后续付款失败、重复购买、退款这些场景全部没法处理。正确做法是：订单表是交易凭证，报名表是权益结果，订单支付成功后才生成报名记录，两边通过order_id关联。这条设计一旦做对，整个系统的业务逻辑就稳了一大半。
1.3 这类系统真正费时间的地方
把用户、课程、讲师这些基础CRUD写完大概只需要整个项目三分之一的时间，剩余时间基本都耗在三个地方：
- 订单状态流转：待支付、已支付、已取消、已退款、已关闭，每个状态有哪些触发动作、哪些接口允许执行，需要理清状态机逻辑。
- 课程内容权限控制：怎么判断当前用户有没有资格访问某个章节的视频/文档，这部分涉及JWT用户身份解析和报名关系校验。
- 后台统计报表：管理员需要看课程销量、营收总额、热门课程排行，这些数据需要做聚合查询，也是答辩时最容易被追问的"系统亮点"。
这三块做好了，系统给人的感觉才不是"玩具"，而是"能扛得住真实业务场景的设计"。
2. 技术选型复盘：为什么是SpringBoot2+Vue3+MyBatis-Plus+MySQL8.0这套组合
我知道肯定有人会问：SpringBoot3都出了，为什么还要用SpringBoot2？Vue3搭配Element Plus稳不稳？MyBatis-Plus会不会引入太多魔法？MySQL8.0和5.7到底差在哪？这些问题我在开发中每一个都认真考虑过，下面把我的判断逻辑摊开讲。
2.1 SpringBoot2：毕业设计和中小型项目的稳妥底座
SpringBoot2直到现在依然是Java服务端生产环境的主流版本。原因不是它比3强，而是稳、熟、资料多。SpringBoot3强制要求JDK17，而且包名从javax.*迁移到jakarta.*，很多老教程和现成代码片段在SpringBoot3下直接编译不过。线上辅导班这种业务，没有任何非用SpringBoot3不可的理由，反而会在环境配置上浪费大量时间。SpringBoot2配JDK1.8或JDK11，是目前压力最小、教程最全、遇到问题一搜就有答案的组合。选型的第一原则永远是"降低不确定性"，而不是"追最新版本"。
2.2 Vue3的Composition API：逻辑聚合让复杂功能变清爽
Vue3现在已经非常成熟，生产环境可以放心用。跟Vue2比，最核心的变化是Composition API（组合式API），它解决了Vue2里"同一个功能的代码被拆散到data、methods、watch各个选项里"的痛点。拿辅导班系统的"课程购买"功能举例：页面要同时处理订单状态、支付按钮状态、倒计时、订单号展示、报名成功提示。Vue2的Options API写法下，这些逻辑的变量散落在data，方法散落在methods，监视器散落在watch；用Vue3的<script setup>语法糖，这些状态和函数可以按功能聚在一起，维护起来舒服得多。
UI框架方面，后台管理部分我建议直接上Element Plus，它是Element UI的Vue3版本，表格、表单、弹窗、分页、上传组件全都有，遇到问题搜一下基本都是现成答案。如果你想要更精致的视觉风格，可以选Ant Design Vue，但资料和踩坑案例相对少一些。做课题、做交付，优先保证"查得到解决方案"。
2.3 MyBatis-Plus：把CRUD从体力活里解放出来
MyBatis-Plus不是替代MyBatis，而是在MyBatis之上做增强。核心价值在于通用Mapper和条件构造器。像线上辅导班这种业务，90%的数据操作是单表CRUD、分页、条件查询。用MyBatis-Plus，你连XML文件都不用写，实体类继承BaseMapper<T>就自动获得了selectById、insert、updateById、deleteById等方法。
举个例子，课程分类的树形查询在纯MyBatis里要写递归SQL，或者写ResultMap嵌套映射。用MyBatis-Plus就简单了：先用QueryWrapper把所有分类查出来，内存里组装成树形结构。分类表数据量不大，多一次全表查询性能完全没问题，但代码量少了一半，逻辑也更直白。另一个常用场景是分页查询，配合MybatisPlusInterceptor注册分页插件，Page<T>直接传页码和页大小，前端分页从此告别手写LIMIT ? , ?。
2.4 MySQL8.0：不是跟风，是真实使用体验更好
MySQL8.0发布到现在已经很多年，稳定性早就验证过了。选择8.0有几个非常实际的理由：
- 默认字符集是utf8mb4，能原生支持emoji和特殊字符，在线教育系统里学生的昵称、作业留言经常出现emoji，5.7的
utf8字符集插入四字节字符时直接报错。 - 窗口函数（
ROW_NUMBER()、RANK()、SUM() OVER()）做课程热度排名、销售统计非常方便，一条SQL搞定，不用写复杂的子查询。 - 既然是新项目，没有理由选老版本。
需要提醒的是MySQL8.0默认认证插件是caching_sha2_password，旧版本的客户端（尤其是很老的Navicat）会连接失败。解决方案是使用MySQL官方mysql-connector-j8.x驱动，并在连接串里指定serverTimezone=Asia/Shanghai，这一点在第5部分我会再详细说。
3. 核心模块落地：从数据库设计到接口实现
这一节是整个系统的"技术含金量"所在，我会从用户认证、课程设计、订单流程、答疑作业四个模块挑重点讲，每个模块都给出可以直接落地的表结构和实现思路。
3.1 用户认证与JWT的落地细节
前后端分离项目的认证绕不开JWT（JSON Web Token）。登录流程是：用户提交账号密码，后端校验通过后生成一个包含用户id、用户名、角色、过期时间的token返回给前端，前端存在localStorage，后续每个请求都在Header里带Authorization: Bearer <token>。后端写一个拦截器HandlerInterceptor，校验token并解析出当前用户，放入ThreadLocal供业务层使用。
实现时有几个坑要提前避：
- 过期时间别设太短。辅导班的学生可能上午登录、下午还在用，过期时间建议至少2小时；如果做了"记住我"，可以放宽到7天。
- 拦截器排除路径要写全，至少包括登录、注册、验证码、Swagger文档、前端静态资源这几类。
- 封号或改密后旧token依然有效。简单项目不引入Redis的话，可以在token里带上用户状态字段，拦截器每次解析后查一次用户状态表，发现异常直接拒绝。
后端生成JWT的代码逻辑不复杂，但签名密钥一定要放到配置文件里，不要硬编码到代码中。密钥建议至少32位随机字符串，并且区分开发环境和生产环境。
3.2 课程与讲师模块的数据库设计
课程模块看起来就是一张course表加一张teacher表，实际上有几个细节值得认真设计：
课程表建议字段：id、title、cover_image、category_id、teacher_id、price、original_price、status（0草稿/1上架/2下架）、intro、create_time、update_time。其中status控制课程是否在商城展示，管理员审核或讲师编辑后置为草稿。
课程章节表建议字段：id、course_id、chapter_title、sort、video_url、content、duration。章节排序用sort字段，查询时ORDER BY sort ASC，不要在业务逻辑里硬编码顺序。
讲师表：我建议基于user表扩展，user表加role字段（STUDENT/TEACHER/ADMIN），讲师专属信息（头衔、简介、擅长领域）单独建teacher_profile表，通过user_id关联。这样账号体系、登录逻辑、权限判断全部复用一套，不用另外维护一套讲师账号。
分类表用category表加parent_id字段支持两级分类就足够了，线上辅导班常见分类就是"数学、英语、编程"这类，两级分类足够用。多级分类会牵扯前端Tree组件的无限递归渲染和后端递归查询，复杂度成倍上升，收益却很低。
3.3 订单流程：最容易被答辩老师追问的地方
订单模块做得好，整套系统的"含金量"立刻上一个台阶。表结构建议：
order表：id、order_no、user_id、course_id、amount、status（0待支付/1已支付/2已取消/3已退款）、pay_method、pay_time、create_time。student_course报名表：id、student_id、course_id、order_id、create_time，加唯一索引(student_id, course_id)防止重复报名。
下单核心流程是：创建订单（生成订单号）→ 模拟支付或调起真实支付 → 支付成功回调 →事务性更新订单状态、写入报名记录、扣减余额。这三步必须在一个@Transactional事务中执行，任何一步失败都要回滚，否则会出现"订单已支付但课程权限没开通"的数据不一致。
写事务时有一个很多新手没注意的坑：同类内this调用不会走Spring代理，事务注解失效。比如OrderServiceImpl里的createOrder方法调用了同类中的paySuccess()，在paySuccess()上加了@Transactional也是无效的。解决办法是把涉及事务的方法放到另一个Bean里，或者自己注入代理对象。
订单号生成建议用yyyyMMddHHmmss + 随机数，长度在20位左右，保证业务上可读且不易重复。不要用数据库自增id当订单号，很容易暴露业务量。
3.4 答疑与作业提交：系统完整度从"有"到"能用"的分水岭
很多辅导班系统做完课程和订单就停了，答疑和作业模块缺失，答辩时老师一句"学生怎么和老师互动？"直接卡壳。其实这两个模块实现成本很低，但对业务闭环非常重要。
答疑模块：question表（id、course_id、student_id、title、content、create_time）、answer表（id、question_id、teacher_id、content、create_time）。学生提问走公开或定向都行，讲师回复后，学生端能看到回复内容。查询时注意权限过滤：讲师只看得到自己课程下的提问，学生只看得到自己发的提问。
作业模块：homework表（id、course_id、title、content、deadline）和homework_submit表（id、homework_id、student_id、content、file_url、score、comment、submit_time）。提交功能支持附件上传（建议用本地存储或对象存储OSS），讲师批改时填分数和评语。作业提交记录要加(homework_id, student_id)唯一约束，确保同一份作业只能提交一次，如需重交则做更新操作。
这两个模块做完，系统给人的感觉就是"真的能运行"，而不是"为了凑功能而存在的demo"。我见过不少答辩优秀的学生项目，技术难度未必高，但业务闭环完整度是实打实的加分项。
4. 从零跑通项目：环境准备与启动全流程
这一部分写给刚拿到源码、还不知道怎么把项目跑起来的人。环境配置不复杂，但版本一定要对，很多问题都出在"自作主张升级了版本"。
4.1 环境清单与版本对应关系
强烈建议严格按照下面的版本组合，不要随意改动：
| 组件 | 版本 | 说明 |
|---|---|---|
| JDK | 1.8 或 11 | SpringBoot2兼容性最好的版本区间 |
| Maven | 3.6+ | Java依赖管理工具 |
| Node.js | 16.14+ | Vue3与Vite的运行环境 |
| npm/yarn | 8+ | 前端依赖安装工具 |
| MySQL | 8.0 | 数据库 |
| Redis | 5.0+（可选） | 做验证码、token黑名单时使用 |
后端IDE建议用IDEA（社区版即可），前端用VSCode或WebStorm都行。前端脚手架用的是Vite，不是Vue CLI，Vite的冷启动速度快一个数量级，改代码热更新的体验也好很多。拿到项目后，如果前端目录下没有node_modules，先执行npm install。这一步如果下载很慢，先设置镜像源：
npm config set registry https://registry.npmmirror.com很多同学卡在npm install卡半小时，其实多半是没配镜像源。
4.2 后端启动步骤
后端启动分为四步，每一步都可能出问题，我按顺序写清楚：
- 用IDEA打开后端工程，进入
File → Settings → Maven检查Maven路径和settings.xml，确认用的是JDK1.8或11，不是JDK17。 - 修改数据库配置，打开
src/main/resources/application.yml，重点检查这段配置：
spring: datasource: url: jdbc:mysql://localhost:3306/tutor_db?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false username: root password: 你的数据库密码 driver-class-name: com.mysql.cj.jdbc.Driver- 创建数据库并导入初始化脚本。MySQL8.0建库命令正确写法：
CREATE DATABASE tutor_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;然后使用MySQL客户端（命令行或Navicat）执行源码里sql/init.sql脚本，导入表结构和初始数据。 4.运行主启动类，找到TutorApplication.java，右键运行，看到日志输出Started TutorApplication就是启动成功。
接口自测建议用Postman或ApiPost，先调登录接口获取token，再在请求Header中加上Authorization，这样能模拟前端真实调用链，比在浏览器里直接敲URL靠谱。
4.3 前端启动步骤
前端启动三步走：
- 用VSCode打开前端目录（通常叫
frontend或vue-ui）。 - 执行
npm install安装依赖，这一步没问题的话继续下一步。 - 找到
.env.development文件，确认API地址指向：
VITE_API_BASE_URL=http://localhost:8080/api然后执行npm run dev，浏览器访问http://localhost:5173进入系统。
前端一个常见问题是：刷新页面变成404。原因是Vue Router用了createWebHistory（HTML5 History模式），刷新时浏览器请求了后端不存在的路径。解决办法有两个：一是在开发环境改用createWebHashHistory路由模式，URL里会带#，但不受服务器配置限制；二是让后端把非API路径全部转发到index.html。对于本项目，开发阶段直接改createWebHashHistory最省事。
4.4 前后端联调最隐蔽的坑：跨域
前端跑在5173端口，后端跑在8080端口，浏览器会认为是两个源，跨域问题绕不开。后端要配置CorsFilter：
@Configuration public class CorsConfig { @Bean public CorsFilter corsFilter() { CorsConfiguration config = new CorsConfiguration(); config.addAllowedOrigin("http://localhost:5173"); config.addAllowedMethod("*"); config.addAllowedHeader("*"); config.setAllowCredentials(true); UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource(); source.registerCorsConfiguration("/**", config); return new CorsFilter(source); } }这里有个经验：addAllowedOrigin不要用"*"，尤其在allowCredentials(true)同时开启的情况下，部分SpringBoot2.x版本会直接报错。前端地址写死是对的，因为线上环境前端和后端域名本来就固定。还有一个容易误判的点是：登录接口出现跨域报错但看不到响应体，多半是Spring拦截器先拦截了OPTIONS预检请求，要确保登录接口在拦截器排除列表里，或者拦截器直接放行OPTIONS方法。
5. 我实际开发中踩过的坑与处理经验
技术框架本身不难，难的是那些"文档没写但一定会遇到"的小问题。我把开发这套系统中踩过的印象最深的坑整理出来，每个都带着解决方案。
5.1 MyBatis-Plus的逻辑删除陷阱
BaseMapper自带的deleteById默认是物理删除，也就是真从表里删掉那行数据。你想做逻辑删除（用户、订单这类核心数据强烈建议用逻辑删除），必须做两步配置：
第一步，实体类需要逻辑删除的字段加@TableLogic注解：
@TableLogic private Integer deleted;第二步，在application.yml中声明配置：
mybatis-plus: global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0这样才能让删除接口变成执行UPDATE ... SET deleted = 1，而且所有MyBatis-Plus生成的查询都会自动追加deleted = 0过滤条件。但要注意：手写在XML里的原生SQL不会自动加这个条件，需要自己手动补充，否则会出现"逻辑删除的数据还在列表里"的诡异问题。
5.2 Vue3响应式丢失的经典场景
我在做课程列表页时遇到过页面死活不刷新的问题，排查半天发现是响应式丢了。Vue3最常见的响应式丢失有两种：
一种是使用reactive定义对象后，解构赋值导致响应性丢失：
// 错误写法 const state = reactive({ list: [], total: 0 }) const { list, total } = state // 正确做法 const list = ref([]) const total = ref(0) const state = reactive({ list, total })另一种是赋值时进行了深拷贝，比如把接口数据JSON.parse(JSON.stringify(res.data))再赋给ref，此时数据虽然是"新的"，但不会再触发视图更新。记住一个原则：用ref就用ref，用reactive就用reactive，中间不要反复用深拷贝隔离响应式。
还有一个和动态表单相关的坑：如果页面里有"点击添加一行课程信息"的需求，用v-model绑定formRows[index].title时，保证formRows是用reactive([])定义的数组，新增行时formRows.push({ title: '', duration: '' })，这样绑定才会生效。一旦用JSON.parse(JSON.stringify(...))复制数组再赋值，新加的行就绑不上v-model了。
5.3 MySQL8.0的两个实操问题
第一个是连接串的时区问题，很多刚跑项目的人会遇到：
java.sql.SQLException: The server time zone value '...' is unrecognized解决办法是在JDBC连接串里加serverTimezone=Asia/Shanghai。第二个问题是驱动包版本，如果用Maven引依赖，推荐用：
<dependency> <groupId>com.mysql</groupId> <artifactId>mysql-connector-j</artifactId> <version>8.0.33</version> </dependency>mysql-connector-j是官方新版坐标，旧坐标mysql-connector-java目前也还能用但已经不是首选。如果你是手动导入jar包的，千万别拿5.x的驱动去连MySQL8.0，会直接报认证插件错误。顺便说一句，新项目请为数据库单独建一个业务账号，不要全部用root。这不是危言耸听，我见过不止一个同学的库只有一个root用户，等项目分享给别人看时被随手删了库，心态直接崩。
5.4 文档怎么组织，才能让这套源码"含金量"真正配得上标题
这套源码自带文档是很大的优势，但很多人的"文档"就是复制粘贴的模板，答辩老师一眼就能看穿。我建议按下面的清单来组织，每份文档都有明确的用途：
- 需求说明书：写清楚角色、功能清单、业务流程、用例图。重点画一张业务流程图，把"学生购课学习"和"讲师管理课程"两条主链路易失清楚地表达出来。
- 数据库设计文档：每张表的结构、字段含义、ER图都要有。重点说明订单表和报名表分离的设计原因，这里是最容易出彩的部分。
- 接口文档：建议用Swagger/OpenAPI生成，导出PDF或Markdown，内容包括URL、请求参数、返回结构、权限要求。接口文档专业与否，直接影响别人对你代码专业度的判断。
- 部署文档：从环境安装到前后端启动，到常见问题排查，写成步骤清单。哪怕是给你的同学看，这条都能省下大把沟通时间。
- 答辩汇报提纲：把技术亮点（JWT认证、事务控制、拦截器、MyBatis-Plus优化、数据库设计）和业务闭环讲清楚。答辩不是念代码，是讲设计，这部分提前准备效果差别极大。
我个人的习惯是：代码写完第一时间补文档，千万别"等有时间了再写"。等代码放几天再回头，你连当初为什么起这个字段名都可能忘了。写文档过程和代码评审一样，经常能逼自己发现设计上的破绽。
我自己的体会是，这套系统恰好处于一个特别舒服的工程区间：没有堆微服务、没有上分布式中间件，而是把一个垂直的在线教育场景老老实实做透。后端用SpringBoot2把生态和稳定性吃满，前端用Vue3获得现代化的开发体验，持久层靠MyBatis-Plus省下大量模板代码，存储落在MySQL8.0上保持数据可靠性。四个环咬合得很顺，是那种"明眼人一看就知道能跑、能交付、能扩展"的架构。
如果你准备基于它做真实业务，后续有希望扩展的方向是：接入真实微信支付和支付宝支付、用对象存储加CDN承载视频点播、用Redis做登录验证码和课程排行榜。代码层面需要时刻绷紧两根弦：事务边界和数据级权限，这两个点不出问题，系统的稳定性基本就有了保障。
最后再多说一个小技巧：把application.yml里的配置全部写上中文注释，尤其是数据库连接、JWT密钥、文件上传路径这三处。每次迁移环境、交给别人二次开发时，这些注释能省掉大量"这个配置到底什么意思"的沟通成本。这个细节看起来不起眼，但我在深夜排查问题的时候，深深感谢过当初那个愿意写注释的自己。
