SpringBoot+Vue+MySQL实战：家教管理系统毕设全流程指南

每到毕设季，跟我咨询最多的问题就是：题目选什么好？如果你拿的是Java方向，又不想选烂大街的进销存、图书管理系统，那基于SpringBoot+Vue+MySQL的家教管理系统是个非常稳妥的选择——业务不复杂但闭环完整，家长、教员、课程、订单、评价几条主线既能做出深度又能画出好看的架构图。这篇文章整理了从选题、建表、写后端、搭前端、联调部署到准备论文和答辩的完整过程，给正在做这个题目的同学一条可复现的路径。

1. 选题与技术选型：家教管理系统的"为什么"逻辑

1.1 为什么这个题适合毕设，而不是再做一个"管理系统"

先说实话，每年有大量学生做"XX管理系统"，但很多题目其实撑不起一篇像样的论文。原因很简单：业务太薄。一个单表增删改查加个登录，页面翻来覆去就是那几张表，论文里系统设计一章根本写不满。

家教管理系统不一样。它的业务天然带角色：家长要发需求、约课、评价，教员要浏览需求、接单、记课时、收订单，管理员要审核、统计、冻结账号。三个角色互相作用，产生的数据流和状态流转就有内容可写，前端页面形态也更丰富——需求大厅可以做成卡片流，课程表能做成时间线，评价可以做成评分组件。这些在论文的"系统实现"章节里全是实打实的截图素材。

再说就业角度。SpringBoot + Vue + MySQL这个组合是目前Java后端岗位最主流的日常开发组合，面试官问SpringBoot自动配置、Vue组件通信、MySQL索引事务，你毕设做过一遍，答起来比别人背书强得多。做这个题目不是为了交差，是给简历上攒一个能讲清楚的项目。

1.2 三大件选型的真实考量：版本配比决定成败

SpringBoot、Vue、MySQL这三个东西大家都会写，但版本配比是第一个坑。我见过很多同学卡在这上面：SpringBoot用了3.x，结果JDK还在8，启动直接报错；MySQL装了8.0，驱动没换，连接一串红。这里直接给一套验证过没问题的组合：

实战中建议SpringBoot选2.7而不是3.x，因为3.x要求JDK17且很多老教程的写法已经不适用了。网上搜代码时，你会发现大多数博客和毕业设计项目都是SpringBoot 2.x环境，你跟着跑不会踩版本坑。Vue这边，如果之前没系统学过，我更推荐Vue2 + Element UI，组件生态成熟、报错能搜到答案；如果有Vue3基础再上Element Plus。

2. 数据库设计：把业务闭环拆成12张表

2.1 核心实体关系：家长、教员、课程怎么串成业务闭环

很多人拿到题目第一反应是设计一大堆表，我见过清单列了29张表的。但毕设不是做ERP，表多了自己维护不住，论文篇幅反而被撑得空洞。合理的表数量在10张左右，核心是让"一个业务闭环跑通"。

家教管理系统的闭环我这样定义：

家长发布家教需求 -> 教员浏览需求并接单 -> 系统生成课程/订单 -> 按课时记录进度 -> 家长对完成的课程评价 -> 管理员全程可审核管理。

这条链路上涉及的实体：用户（角色区分）、家教需求、订单、课程记录、评价。再加辅助表：科目分类、收藏、留言、公告、操作日志。一共12张表，不多不少，写论文时每张表都有角色。

2.2 表结构落地方案：12张表怎么设计

最核心的是用户表。家教系统里用户就一张表，靠role字段区分家长、教员、管理员，比分三张表存要方便得多——登录时查一次就定位身份，不用去三张表里遍历。

sql复制CREATE TABLE `user` (
  `id` bigint NOT NULL AUTO_INCREMENT,
  `username` varchar(50) NOT NULL COMMENT '登录用户名',
  `password` varchar(100) NOT NULL COMMENT 'BCrypt加密后的密码',
  `real_name` varchar(50) DEFAULT NULL COMMENT '真实姓名',
  `role` tinyint NOT NULL DEFAULT '1' COMMENT '0管理员 1家长 2教员',
  `phone` varchar(20) DEFAULT NULL,
  `avatar` varchar(200) DEFAULT NULL,
  `status` tinyint DEFAULT '1' COMMENT '1正常 0冻结',
  `create_time` datetime DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_username` (`username`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

注意两个细节：密码不要明文存，用Spring Security的BCrypt加密，这在你论文的安全性分析里是加分项；create_time字段不要用timestamp类型，用datetime，避免2038年问题，虽然毕设无所谓，但答辩老师看了会觉得你有常识。

家教需求表是家长端的核心表。字段要能支撑"家长按科目、区域、年级筛选教员"的场景：

sql复制CREATE TABLE `demand` (
  `id` bigint NOT NULL AUTO_INCREMENT,
  `parent_id` bigint NOT NULL COMMENT '发布人',
  `subject_id` bigint NOT NULL COMMENT '科目',
  `grade` varchar(20) DEFAULT NULL COMMENT '年级',
  `area` varchar(50) DEFAULT NULL COMMENT '所在区域',
  `price_ceiling` int DEFAULT NULL COMMENT '每小时预算',
  `detail` text COMMENT '需求描述',
  `status` int DEFAULT '0' COMMENT '0待接单 1已接单 2已完成 3已取消',
  `create_time` datetime DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

订单表和课程表建议分开。接单后生成订单，课程表按课时生成多次记录，这样家长晒课时、教员记上课次数都方便。评价表挂订单而不是挂用户，这样一条订单只能评价一次，业务上说得通，也避免重复评价的问题。

这里要特别提醒：所有外键关系不要在数据库层面强制加约束，逻辑关联就好。毕设里加了外键，删数据时各种报错，演示环节很容易翻车；用逻辑外键，代码里控制关联，反而灵活。

2.3 ER图与论文素材：不要手动画，工具的导入导出

论文要配ER图，别用Visio手动画，工程量大还容易画错。如果你用Navicat，直接右键模型反向生成ER图；用MySQL Workbench也行，它能根据库表自动生成EER图。更省力的方式是先用ChatGPT生成一段数据库设计文档，再对着你实际的表结构调整字段描述，最后用工具出图。这一步能帮你省一个周末。

画好的ER图建议存两张：一张整库全表的，放论文"数据库设计"章的整体预览；一张只截核心业务链（用户、需求、订单、课程、评价）的，放"核心功能设计"章里做局部说明。两张图一详一略，答辩时讲起来有层次。

3. SpringBoot后端：JWT鉴权与核心业务链路的落地写法

3.1 项目结构：controller-service-mapper怎么分工

后端工程结构一定要清晰，这不光是为了你自己好找代码，答辩时老师会直接看目录结构。我的做法是标准的Controller -> Service -> Mapper三层，加一个common包放通用类。

code复制com.example.tutor
├── common          # 统一返回结果、异常处理、常量
├── config          # 配置类，如跨域、拦截器注册
├── controller      # 接口层，只做参数接收和结果封装
├── entity          # 数据库实体类
├── mapper          # MyBatis-Plus接口
├── service         # 业务逻辑层
│   └── impl
├── utils           # JWT工具、日期工具等
└── vo              # 视图对象，比如登录后的用户信息

Controller里只写路由和参数校验，真正的逻辑全放Service。举个例子：家长发布需求这个操作，Controller拿到前端传的DTO后，直接调用demandService.publish(demandVo)，里面处理用户身份校验、字段补全、状态初始化。这样每个方法职责单一，学生写起来不容易乱，答辩讲的时候也理直气壮。

3.2 登录认证方案：为什么用JWT而不是Session

毕设最常见的登录写法是Session，但当前企业开发里JWT才是主流。我从一开始就选了JWT，理由有三个：前后端分离的项目，后端不维护Session，扩展性好；JWT无状态，微服务下也好用；面试和论文里可写的内容多。

核心实现分三块：登录时签发Token、拦截器校验Token、ThreadLocal保存当前登录用户。登录接口大概长这样：

java复制@PostMapping("/login")
public Result<?> login(@RequestBody LoginDto dto) {
    // 1. 查询用户并校验密码（BCrypt验证）
    User user = userService.login(dto.getUsername(), dto.getPassword());
    // 2. 登录成功生成JWT，payload里放userId和role
    String token = JwtUtil.generateToken(user.getId(), user.getRole());
    // 3. 返回用户信息和token给前端
    return Result.success(new LoginVo(user, token));
}

Token生成后，前端每次请求在Header里带Authorization: Bearer xxx，后端拦截器里统一解析。如果Token过期或者伪造，直接返回401，前端收到后跳转登录页。这样一套流程干净利落。

需要注意的是：JWT的密钥不能硬编码在代码里，至少放到application.yml配置文件中。虽然毕设没人黑你，但论文写"密钥可配置"也算一个设计亮点。

3.3 核心业务链路实现：从发布需求到完成评价的代码走一遍

这是整篇博文最值钱的部分。我按业务闭环带你走一遍完整代码逻辑。

第一步：家长发布需求。 这里要做的不只是插入一条数据，还要校验家长身份，以及设置订单的初始状态。

java复制public void publish(DemandSaveVo vo) {
    // 从ThreadLocal里取当前登录用户
    User current = UserHolder.get();
    if (current.getRole() != RoleEnum.PARENT.getValue()) {
        throw new BusinessException("只有家长才能发布需求");
    }
    Demand demand = new Demand();
    BeanUtil.copyProperties(vo, demand);
    demand.setParentId(current.getId());
    demand.setStatus(StatusEnum.PENDING.getValue());
    demand.setCreateTime(LocalDateTime.now());
    demandMapper.insert(demand);
}

第二步：教员浏览需求并接单。 接单是最容易写崩的环节，涉及并发问题。比如同一个需求两个教员同时点了接单，怎么只让一个成功？我的做法是接单时用一个UPDATE ... WHERE status=0的原子操作，影响行数为0说明被别人抢了。

java复制@Transactional
public void accept(Long demandId) {
    // 原子更新：只有status还是0的时候才能成功
    int rows = demandMapper.updateStatus(demandId, 
                 StatusEnum.PENDING.getValue(), StatusEnum.ACCEPTED.getValue());
    if (rows == 0) {
        throw new BusinessException("手慢了，该需求已被接走");
    }
    // 生成订单，并初始化12个课时记录
    Order order = new Order();
    order.setDemandId(demandId);
    order.setTutorId(UserHolder.get().getId());
    order.setStatus(OrderStatusEnum.IN_PROGRESS.getValue());
    orderMapper.insert(order);
    initCourseRecords(order.getId(), 12);
}

这里用了@Transactional，接单后生成的订单和课时记录要么都成功、要么都回滚。论文里写"通过事务保证数据一致性"，就是这一段。

第三步：家长确认课时完成并评价。 课程记录表里每节可单独标记完成，全部完成后修改订单状态为已完成，这时家长才可评价。

java复制public void completeCourse(Long courseId) {
    Course course = courseMapper.selectById(courseId);
    course.setStatus(CourseStatusEnum.FINISHED.getValue());
    courseMapper.updateById(course);
    // 如果所有课程都完成，自动完结订单
    completeOrderIfAllFinished(course.getOrderId());
}

评价接口里要校验该订单确实已完结，且评价人就是下订单的家长，再加一条order表的外键属性comment_status，防止重复评价。状态字段流转规则在OrderStatusEnum里统一定义，代码里不要到处写魔法值。

3.4 MyBatis-Plus效率利器：CRUD还能更简单

用原生MyBatis写CRUD会很累，毕设时间宝贵，我直接引入MyBatis-Plus。它最大的价值是单表操作完全不用写SQL：继承BaseMapper后，insert、selectById、updateById全都有。

复杂一点的查询用LambdaQueryWrapper，比如"按科目和区域筛选可用需求"：

java复制LambdaQueryWrapper<Demand> wrapper = new LambdaQueryWrapper<>();
wrapper.eq(Demand::getStatus, StatusEnum.PENDING.getValue());
wrapper.eq(vo.getSubjectId() != null, Demand::getSubjectId, vo.getSubjectId());
wrapper.like(vo.getArea() != null, Demand::getArea, vo.getArea());
wrapper.orderByDesc(Demand::getCreateTime);

这样构造条件比拼SQL安全多了，不会出现SQL注入问题。分页也简单，配置一个拦截器，然后Page<Demand> page = demandMapper.selectPage(new Page<>(1, 8), wrapper);，前端传页码和页大小就行。这里注意：MyBatis-Plus分页要加配置类，否则selectPage只是内存分页，数据量一大就慢。这个坑很多人踩过。

4. Vue3前端：路由守卫、Axios封装与页面组件化

4.1 前端基础搭设：Vue3 + Element Plus + Vite

前端我用的是Vue3 + Element Plus + Vite的组合。Vite启动快、热更新爽，比webpack时代的体验好太多。创建项目用官方脚手架，一个命令搞定：

bash复制npm create vite@latest tutor-web -- --template vue
cd tutor-web
npm install element-plus axios vue-router pinia

Element Plus別全量引入，按需引入体积小，启动也快。配置起来很简单，在main.js里引入基础样式，组件按需使用时直接import，或者干脆全量引入——毕设项目不要纠结性能，全量引入省事，答辩时不会被问首屏加载优化。

4.2 Axios封装与登录态管理

前后端分离最麻烦的是接口调用和Token管理。我建了一个utils/request.js，把Axios实例统一封装：

javascript复制import axios from 'axios'
import { ElMessage } from 'element-plus'
import router from '../router'

const request = axios.create({
  baseURL: '/api',
  timeout: 10000
})

// 请求拦截器：自动带token
request.interceptors.request.use(config => {
  const token = localStorage.getItem('token')
  if (token) {
    config.headers.Authorization = 'Bearer ' + token
  }
  return config
})

// 响应拦截器：统一处理业务码和登录失效
request.interceptors.response.use(
  response => {
    const res = response.data
    if (res.code !== 200) {
      ElMessage.error(res.msg)
      if (res.code === 401) {
        router.push('/login')
      }
      return Promise.reject(res)
    }
    return res.data
  },
  error => {
    ElMessage.error('网络异常，请检查后端是否启动')
    return Promise.reject(error)
  }
)

export default request

路由守卫放在router/index.js里，每次跳转前检查有没有Token和路由meta里的角色要求：

javascript复制router.beforeEach((to, from, next) => {
  const token = localStorage.getItem('token')
  if (to.path === '/login') {
    next()
    return
  }
  if (!token) {
    next('/login')
    return
  }
  // 可选：按角色限制页面访问
  const role = localStorage.getItem('role')
  if (to.meta.roles && !to.meta.roles.includes(Number(role))) {
    ElMessage.warning('没有权限访问该页面')
    next('/dashboard')
    return
  }
  next()
})

这里有一个设计取舍：baseURL设为/api，再在Vite里配置代理转发到后端localhost:8080。这样开发环境不会跨域，生产环境把前端打包进SpringBoot后，/api又会命中后端自己的Controller。一个路径规则两头通吃，省掉一堆跨域配置。

4.3 需求大厅与订单状态展示：组件化思路

前端页面不要一个vue文件写几百行，拆组件是毕设加分项。需求大厅我拆了四个组件：DemandCard展示单条需求卡片，FilterBar做筛选条件，DemandList负责循环渲染，Pagination处理分页。父组件只负责把接口返回的数据传给子组件，子组件通过emit把操作事件抛回来。

展示订单状态用el-tag套不同颜色，状态码转文案抽成一个方法：

javascript复制const statusMap = {
  0: { text: '待接单', type: 'info' },
  1: { text: '已接单', type: 'success' },
  2: { text: '已完成', type: 'warning' },
  3: { text: '已取消', type: 'danger' }
}

这样页面上各处循环都用同一个映射，改动只改一处。同样的思想用在角色显示、科目分类等场景，能让你少写很多重复代码。

5. 联调打包部署：从本地运行到单jar上线

5.1 本地联调的跨域处理方案

开发阶段最容易卡住的是跨域。我推荐用Vite代理，vite.config.js里写一段：

javascript复制server: {
  port: 3000,
  proxy: {
    '/api': {
      target: 'http://localhost:8080',
      changeOrigin: true
    }
  }
}

前端请求/api/login，Vite帮你转发到http://localhost:8080/api/login，浏览器的请求地址始终是localhost:3000，不存在跨域问题。

如果你不想用代理，后端加一个全局CORS配置类也行。但要注意：一旦用了后端CORS配置，前端请求就不能再用代理了，不然会出现二次跨域或者奇怪的Header错误。原理上代理更贴近生产部署方案，毕设推荐用它。

5.2 前后端合并打包：一个jar搞定部署

毕设演示最怕环境问题，最好的办法是打包成单jar，一个文件到处跑。做法分三步：

第一步，前端构建。在tutor-web目录执行npm run build，生成dist文件夹。里面是静态资源，包含index.html、assets目录。注意Vue3+Vite默认打包出来的资源路径是绝对路径/assets/，如果部署在域名子路径下会有问题。Vite里可以改base: './'，这样资源路径变成相对路径，合并进SpringBoot后不会404。

第二步，把dist整个文件夹复制到后端项目src/main/resources/static下面。SpringBoot默认就把static当静态资源目录，什么都不用配。此时启动后端，访问http://localhost:8080就能看到前端页面。

第三步，打jar包。后端执行：

bash复制mvn clean package -DskipTests

然后运行：

bash复制java -jar tutor-system-0.0.1-SNAPSHOT.jar

演示时全程只依赖一个进程和一个MySQL数据库，稳定到可以提前半天布置好环境，答辩当天打开电脑演示五遍都不带慌的。

5.3 答辩演示的节奏与数据准备

一个实用的建议：数据库里提前准备三种角色的演示账号，并且给每种角色准备五六条辨识度高的数据——比如"李老师，数学，3年教龄，擅长初三冲刺"这种，比"用户1"、"用户2"直观得多。演示顺序按业务闭环走：家长登录发布需求 -> 切到教员账号接单 -> 回到家长账号看到已接单 -> 标记课程完成 -> 评价。这一条线走下来，系统核心功能全部覆盖，全程五分钟，节奏紧凑。

答辩时老师大概率会问"如果两个教员同时接单怎么办""密码怎么存的""分页怎么实现的"，这些都是我上面代码里已经写了的点。提前在论文里把事务、JWT、加密这几块标出来，被问到时不慌。

6. 踩坑实录与论文写作的经验补充

6.1 版本兼容性踩坑：JDK版本与SpringBoot版本的关系

前面说了用SpringBoot 2.7.x，但这里有个潜在坑：IDEA自带或系统默认的JDK版本可能很高。比如你装了JDK17，那SpringBoot 2.7虽然也能跑，但Maven编译时会报"无效的目标发行版"之类的问题。解决办法是在pom.xml里明确指定Java版本：

xml复制<properties>
    <java.version>1.8</java.version>
    <maven.compiler.source>1.8</maven.compiler.source>
    <maven.compiler.target>1.8</maven.compiler.target>
</properties>

同时检查IDEA里的Project Structure，把SDK和Language Level都改成8。这个配置说是毕设第一大坑不过分。如果天生喜欢新技术、机器上有JDK17，也可以直接上SpringBoot 3.x，但网上教程大量是2.x的写法，很多注解包路径都变了，自己权衡。

6.2 MySQL连接常见报错与解决办法

我整合了网上和亲测最常见的三个错误：

对应的JDBC URL直接抄这个：

code复制jdbc:mysql://localhost:3306/tutor_db?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false&allowPublicKeyRetrieval=true

另外MySQL 8.0安装时如果之前装过5.7，记得先卸载干净，注册表残留会导致安装不上。网上搜"mysql安装教程"时会发现一堆版本和方法，认准8.0.33左右的稳定版，别追最新。

6.3 Vue路由刷新404与打包路径问题

开发时没有任何问题，打包上线后一刷新页面就404，这是前后端分离项目的经典问题。Vue的history路由模式需要服务器把所有非文件请求都转发到index.html，SpringBoot默认不这么干。

最简单的办法：打包前把路由模式改成hash模式。hash模式下URL带#，资源请求本质是index.html#/xxx，刷新自然不会404。虽然URL丑一点，但毕设只需要稳定运行。如果一定要用history模式，可以加一个控制器把所有非接口路径转发到index.html，但这就涉及一些细节，没必要为了演示好看给自己加戏。

6.4 论文写作：系统实现章节的写法

最后聊论文。很多人代码写完了，论文写不出来，主要卡在"系统实现"这一章。我的建议是这一章不要罗列代码，而是每个核心功能配图、配流程描述、配关键代码段。比如接单功能写三段：业务描述一段（家长发布需求、教员查看大厅、点击接单、状态变更）、截图一张（需求大厅页面）、核心代码段贴上accept方法的实现，再加一句"通过事务控制和原子更新保证并发下数据一致"。这样的结构，每一小节都有说服力，导师一眼就能看出你真的实现了。

测试用例也别只写"输入用户名密码，点击登录，跳转首页"这种。写成表格：功能名、前置条件、操作步骤、预期结果、实际结果，每一项都标注正常流程和异常流程。这部分内容能大幅充实论文篇幅，而且又不需要造假，因为你确实跑过这些功能。

最后说个我自己当时忽略的小细节：做演示前，把数据库里的演示数据准备得"刚刚好"——不要太多显得乱，也不要太少显得空。我当年演示时为了展示分页，把需求数量灌到了100条，结果本身页面非常流畅，翻了两页就翻完了，老师根本没有"分页存在"的感受。后来改成每页刚好显示8条、第二页只有3条的样子，翻页的效果一目了然。这种演示里的小设计，比临时多写一个接口管用得多。家教管理系统的开发本身不难，难的是把每个环节都做得"刚刚好"，论文、代码、演示三者互相支撑，这个毕设基本就稳了。