第一次看到“基于SpringBoot+Vue的教学管理系统设计与实现【Java+MySQL+MyBatis完整源码】”这样的标题，很多人第一反应是：这不就是一个大号增删改查项目吗？等真把源码摊开来看，又会发现“选课并发”“成绩录入”“角色权限”这些业务点，每一处都在考验数据库设计和接口拆分的功力。
这套系统的典型价值在于：前端有Vue的工程化组织，后端有SpringBoot的接口分层，数据库有学生、教师、课程、选课、成绩等完整业务表，再配上MyBatis的手写SQL和动态查询，基本上把JavaWeb开发者在真实项目里会用到的主干技术都串了一遍。如果你正准备做毕业设计、课程设计，或者刚入行想找一个结构完整的前后端分离项目练手，这套系统的源码非常值得仔细读一遍。
1. 先拆需求：一套教学管理系统到底要管哪些事
拿到任何源码，第一步千万别急着启动项目，先把业务边界理清楚。只有知道系统“要干什么”，才能看懂表结构为什么会这样设计，接口为什么会这样拆分。
1.1 从核心角色反推业务清单
教学管理系统最常见的角色有三种：管理员、教师、学生。这三个角色不是简单挂在登录页上好看的，他们决定了整个系统的功能边界。
- 管理员：管人、管课、管全局。需要维护学生和教师的基础档案，开设课程，查看选课统计，必要时重置密码、发布公告。
- 教师：管自己的课。能查看自己名下的课程列表，看到选了自己课程的学生名单，录入和修改成绩。
- 学生：管自己的学习过程。能浏览可选课程、完成选课和退选、查看自己的成绩单。
从这三个角色反推，系统的核心业务模块就很清晰了：用户认证、学生信息管理、教师信息管理、课程管理、选课管理、成绩管理。再加上公告、个人中心这类辅助功能，基本就是一个完整教学管理系统的主干。
1.2 页面清单里藏着业务闭环
很多初学者拿到源码后喜欢直接看代码，我反而建议先从页面清单开始。把系统跑起来后，你会看到这几个典型页面：
- 登录页：所有角色的入口，根据角色跳转到不同首页。
- 管理端首页：展示学生数、教师数、课程数、选课人数等统计指标。
- 学生管理页：管理员维护学生档案，支持分页搜索、新增、编辑。
- 教师管理页：管理员维护教师档案，分配教师与账号的关联关系。
- 课程管理页：管理员开课，指定授课教师、课程容量、学分等。
- 选课大厅：学生查看可选课程，执行选课或退选。
- 成绩录入页：教师选择课程后，按学生名单录入成绩。
- 成绩查看页：学生查看自己的课程成绩和学分汇总。
把页面连起来看，你会发现一个完整闭环：管理员建课 -> 学生选课 -> 教师录入成绩 -> 学生查看结果。后面的数据库设计和接口设计，本质上都是为这个闭环服务的。
1.3 谁适合拿这套源码当教材
如果你属于下面任意一类人群，这套项目都比较对胃口：
- 正在准备毕业设计或课程设计的学生：结构清晰、技术栈常见、业务复杂度适中，用这个骨架做二开很顺手。
- 想从前端转全栈的开发者：Vue部分难度不高，后端接口有典型的分层结构，能帮你建立前后端联调的感觉。
- 刚接触SpringBoot不久的人：通过一套完整业务系统理解Controller、Service、Mapper到底怎么配合，比看零散demo有效得多。
对我来说，真正值得反复研究的是它的“取舍”。为什么角色权限用字段而不是五张RBAC表？为什么成绩挂在选课表里而不是单独建表？这些细节才是源码里的隐藏价值。
2. 技术选型为什么是这四件套：SpringBoot、Vue、MyBatis、MySQL
标题里把这四个技术写出来，不是随便凑的。它们组合在一起，几乎是当前中小型管理系统开发里最稳、最不出错的一套搭配。
2.1 后端选SpringBoot，核心是省掉配置工程
早些年写JavaWeb要面对大量XML配置，数据源、事务、组件扫描都要手搓。SpringBoot把这些东西全部收敛为“约定优于配置”，依赖用起步依赖引入，配置写在application.yml里，内嵌Tomcat让项目能打成jar直接跑。
这套系统的后端，你会看到清晰的四层结构：Controller接收请求、Service处理业务、Mapper访问数据库、实体类映射表结构。对学习者来说，这种分层是教科书级别的规范，每一层职责都很明确，出了问题也能快速定位。
2.2 Vue+Element UI解决后台管理页面的什么痛点
后台管理系统的页面无非是表格、表单、弹窗、分页、导航菜单这几类。Vue的组件化机制配合Element UI，可以让这些重复度极高的界面变成可复用的组件封装。
选择Vue而不是其他框架，还有一个很现实的原因：社区资料实在太多了。选课页面怎么写、路由守卫怎么配、Axios怎么拦截，几乎你能踩到的每个坑，网上都有现成的讨论结果。对毕设和课设来说，这能省掉大量排查时间。
Vue版本方面，我建议以Vue2为主线看。不是因为Vue2比Vue3好，而是因为这套源码配套的Element UI在Vue2下最稳定，相关资料最全，适合先把系统跑通，再根据需求升级。
2.3 标题里的MyBatis为什么值得多看一眼
现在很多新项目已经用MyBatis-Plus了，但标题特意写MyBatis，意味着这是原生半自动ORM的写法。SQL要自己写，结果映射要自己配，乍一看好像是麻烦了点，但这恰恰是学习价值所在。
手写SQL能让你真正理解多表关联、动态条件拼接、结果集映射这些数据库基本功。比如课程列表要关联教师表查出教师姓名，原生MyBatis里可以用resultMap，也可以在SQL里直接给字段取别名，两种方式各有适用场景。
如果你以后要接手老项目，原生MyBatis仍然大量存在，掌握XML里的动态SQL写法会比只会用Plus的通用方法实用得多。
2.4 版本搭配：别让环境成为第一个坑
技术选型里隐藏的第一个大坑就是版本兼容。一套很稳的配置大概是这样的：
| 组件 | 推荐版本 | 说明 |
|---|---|---|
| JDK | 1.8 | 最容易兼容的版本，避免升级到17/21后碰到框架问题 |
| SpringBoot | 2.7.x | 稳定且资料多，不建议直接用3.x |
| MyBatis | 3.5.x | 配mybatis-spring-boot-starter 2.x |
| MySQL | 5.7或8.0 | 8.0注意驱动类和时区参数 |
| Vue | 2.6.x | 配合Element UI 2.15.x |
| Node | 16.x | Vite和某些依赖对Node版本敏感，16相对稳妥 |
这个表格看起来不起眼，但能帮你省掉大量环境问题。我见过太多人卡在启动阶段，最后发现是JDK版本过高导致Lombok插件异常，或者MySQL8驱动类没改。
3. 数据库设计：如何支撑选课、成绩这类核心场景
后端代码写得再漂亮，表结构设计不合理，系统一样跑不顺。教学管理系统里最考验设计的，就是用户档案、课程关系、选课唯一性这三块。
3.1 用户、学生、教师：需要三张还是两张表
常见的错误设计是把学生、教师的所有字段都塞进一张用户表，结果表里一堆字段在某种角色下永远为空，维护起来很痛苦。
更合理的做法是拆成“账号表+档案表”。账号表统一保存登录名、密码、角色、状态；学生档案和教师档案分别保存各自特有信息，通过用户ID关联。
CREATE TABLE sys_user ( id BIGINT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL UNIQUE COMMENT '登录账号', password VARCHAR(100) NOT NULL COMMENT 'BCrypt加密后的密码', role TINYINT NOT NULL COMMENT '1管理员 2教师 3学生', real_name VARCHAR(50) COMMENT '真实姓名', status TINYINT DEFAULT 1 COMMENT '1启用 0禁用', deleted TINYINT DEFAULT 0 COMMENT '逻辑删除：0正常 1删除', create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP );角色这里直接用字段，而没有设计成user_role、role、permission那套标准RBAC五表模型，是因为教学管理系统的角色非常固定，不会出现“某个管理员只能管理某一个学院的课程”这种细粒度需求。简化角色模型能显著降低理解成本和查询复杂度。
3.2 课程、选课、成绩的关系设计
课程表要跟教师表关联，选课表要同时关联学生和课程，成绩复用选课表的score字段，这样一套关系就能覆盖核心业务。
CREATE TABLE course ( id BIGINT PRIMARY KEY AUTO_INCREMENT, course_no VARCHAR(20) NOT NULL COMMENT '课程编号', course_name VARCHAR(100) NOT NULL, teacher_id BIGINT NOT NULL COMMENT '授课教师ID', credit DECIMAL(3,1) DEFAULT 2.0, hours INT DEFAULT 32, capacity INT DEFAULT 60 COMMENT '容量', selected_count INT DEFAULT 0 COMMENT '已选人数', semester VARCHAR(30) COMMENT '开课学期', deleted TINYINT DEFAULT 0, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE course_selection ( id BIGINT PRIMARY KEY AUTO_INCREMENT, student_id BIGINT NOT NULL, course_id BIGINT NOT NULL, score DECIMAL(5,2) DEFAULT NULL COMMENT '成绩，未录入为NULL', create_time DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uniq_student_course (student_id, course_id) );选课表加唯一索引是最重要的一个决策。没有这个索引，同一学生疯狂点击选课按钮时极容易插入两条重复记录，后续查成绩、算学分都会出问题。
物理外键我建议不加。表与表之间的关联通过业务代码保证，减少删除数据时被外键拦截的麻烦。逻辑关联比物理外键灵活得多，这也是主流做法。
3.3 字段规格：下划线命名、逻辑删除与唯一索引的取舍
这部分经验都是从实际填坑里攒出来的。
首先是下划线字段名和Java驼峰属性的映射。数据库字段叫course_name，实体类属性叫courseName，如果没开启驼峰映射，查询结果里courseNname就是null。对应的配置是：
mybatis: configuration: map-underscore-to-camel-case: true逻辑删除字段设计成deleted TINYINT，默认0。这里有个隐蔽的坑：如果学生表里学号student_no上有唯一索引，逻辑删除一条记录后，这个学号仍然被占用，下次再导入同一个学号会直接报唯一索引冲突。解决思路通常是删除时同时修改原记录的学号或者状态标记，或者干脆物理删除，这一点在二次开发时需要结合业务决定。
时间字段统一用DATETIME，让数据库自动生成create_time，update_time用ON UPDATE CURRENT_TIMESTAMP自动更新。Java实体里对应LocalDateTime，返回给前端时要处理好序列化格式，否则前端拿到的是数组而不是时间字符串。
4. 后端实现：登录认证、权限控制与业务接口设计
后端是整个系统的中枢。跑通登录、控制角色权限、写清业务接口，这三件事几乎是所有功能页面的前提。
4.1 登录流程与JWT令牌的落地
登录接口的流程本身不复杂，难点在于密码安全和会话保持。密码在数据库里不能存明文，应该用BCrypt加密；登录成功后，后端签发一个JWT令牌，前端保存到本地存储，后续每个请求都在请求头里携带。
@PostMapping("/login") public Result<LoginVO> login(@RequestBody LoginDTO dto) { User user = userService.findByUsername(dto.getUsername()); if (user == null || !BCrypt.checkpw(dto.getPassword(), user.getPassword())) { return Result.error("用户名或密码错误"); } if (user.getStatus() == 0) { return Result.error("账号已被禁用"); } String token = JwtUtil.createToken(user.getId(), user.getRole()); return Result.success(new LoginVO(token, user.getRole(), user.getRealName())); }签发token之后，每个需要登录的接口都要校验token。最简单的实现是写一个HandlerInterceptor，在preHandle方法里读取请求头Authorization，解析token，再把用户ID放到request属性里供Controller使用。登录接口本身要放行，静态资源路径也要放行，否则前端页面都进不来。
4.2 统一返回体与全局异常
我强烈建议所有接口都返回统一结构Result。只要前端能约定好code、message、data三层含义，联调效率会高很多。
public class Result<T> { private Integer code; private String message; private T data; }配合@RestControllerAdvice做全局异常捕获，把业务异常、参数校验异常、未知异常分别处理。这样后端即使抛了异常，前端收到的仍然是一个结构完整的JSON，而不是一堆服务端错误堆栈。
4.3 核心业务接口清单
下面这张接口表基本覆盖了一个教学管理系统的主干功能，也是我研究这类源码时最关注的部分。
| 功能点 | 接口路径 | 角色 | 说明 |
|---|---|---|---|
| 登录 | POST /api/auth/login | 匿名 | 签发JWT |
| 学生分页查询 | GET /api/students/page | 管理员 | 支持姓名、班别筛选 |
| 新增学生 | POST /api/students | 管理员 | 创建账号并绑定学生档案 |
| 删除学生 | DELETE /api/students/{id} | 管理员 | 逻辑删除 |
| 课程分页查询 | GET /api/courses/page | 管理员/学生 | 可带课程名、教师筛选 |
| 开设课程 | POST /api/courses | 管理员 | 指定教师、容量 |
| 选课 | POST /api/selections | 学生 | 事务内校验容量 |
| 退选 | DELETE /api/selections/{id} | 学生 | 事务内递减已选人数 |
| 我的课程列表 | GET /api/selections/my | 学生 | 关联课程和成绩 |
| 按课程查学生名单 | GET /api/scores/{courseId}/students | 教师 | 教师只能查自己的课程 |
| 录入成绩 | PUT /api/scores | 教师 | 校验0-100分 |
这里有个细节值得反复强调：教师查询学生名单时，后端不能只听前端传一个课程ID，还要根据当前登录用户ID去校验“这门课是不是这个教师的”。否则学生只要改一下请求参数，就能看到别人的课程数据。权限校验放在业务逻辑里，而不只是靠前端隐藏按钮。
4.4 MyBatis动态SQL与多表查询的书写经验
原生MyBatis最常用的场景就是条件查询。拿课程管理列表来说，管理员搜索时可能按课程名、教师名、学期任意组合筛选，如果写死SQL，每多一个条件就要复制一遍查询，几乎没法维护。
用动态SQL可以优雅解决：
<select id="selectCoursePage" resultType="com.example.vo.CourseVO"> SELECT c.id AS courseId, c.course_no AS courseNo, c.course_name AS courseName, c.credit, c.capacity, c.selected_count AS selectedCount, c.semester, t.real_name AS teacherName FROM course c LEFT JOIN sys_user t ON c.teacher_id = t.id <where> <if test="courseName != null and courseName != ''"> AND c.course_name LIKE CONCAT('%', #{courseName}, '%') </if> <if test="semester != null and semester != ''"> AND c.semester = #{semester} </if> </where> ORDER BY c.create_time DESC </select>这里的三个关键点：表连接用别名避免字段歧义；查询结果字段全部取别名映射VO；动态条件用 标签自动处理AND拼接。分页可以直接用PageHelper，在查完数据后返回PageInfo，前端一次性拿分页数据和总条数。
5. 前端Vue组织与联调：从页面到接口的细节
后端接口写得再规范，前端不会联调依然白搭。Vue这部分的价值主要集中在目录结构、请求封装、跨域代理和核心交互四个地方。
5.1 目录结构与路由权限
一个清晰的前端目录结构能让人少走很多弯路。核心结构可以参考：
src/ api/ // 按业务模块封装接口请求 router/ // 路由配置 store/ // 用户状态、token状态 views/ // 页面级组件 components/ // 公共组件（分页表格、上传等） utils/request.js // axios实例和拦截器路由权限不必做到动态注册那么复杂。静态路由定义好每个页面所需要的角色，在路由守卫里判断当前用户角色是否在允许列表里就行。这套系统角色只有三种，用简单方案更合适，也更容易看懂。
5.2 Axios封装：携带token与统一处理错误
如果每个页面都单独引入axios，代码会非常散。更合理的做法是统一封装一个request实例，在请求拦截器里自动添加token，在响应拦截器里处理统一返回结构和登录失效。
import axios from 'axios' const request = axios.create({ baseURL: '/api', timeout: 10000 }) request.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers.Authorization = 'Bearer ' + token } return config }) request.interceptors.response.use( res => { const code = res.data.code if (code === 401) { localStorage.removeItem('token') window.location.href = '/login' return Promise.reject(new Error('登录已过期')) } return res.data }, err => Promise.reject(err) )注意登录失效的处理一定要放在响应拦截器里统一做，否则每个页面都要写一遍“跳到登录页”的逻辑，很容易漏。
5.3 前后端跨域联调
前后端分离项目，开发环境最常见的坑就是跨域。后端接口在8080端口，前端页面在8081端口，直接请求必然被浏览器拦截。
开发阶段最简单的方案是在vue.config.js里配置代理：
module.exports = { devServer: { port: 8081, proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } } }这里的关键是理解：开发环境代理解决的是浏览器和前端开发服务器之间的跨域；后端接口部署到Nginx后，还要再做一次反向代理配置。很多人在本地跑通了，一部署到服务器就白屏、接口404，多半是Nginx配置里少了location转发。
5.4 选课和成绩录入的页面交互细节
前端页面的核心交互里，选课和成绩录入最能体现工程经验。
选课按钮最怕连点。接口还没返回时，用户快速点击两次，如果后端没有做幂等控制，就可能插入两条相同记录。前端在点击后立即把按钮设为loading或disabled状态，等接口返回后再恢复。这一步虽然简单，但对体验提升非常明显。
成绩录入页面则要处理好表格联动。教师先选一门课程，后端返回这门课的学生名单，然后每行一个输入框和一个保存按钮。提交时必须做分数范围校验，0到100之间才允许发送请求，避免后端被无效数据干扰。
6. 跑通项目与二次开发：配置、启动、上线经验
源码拿到手，最终目标是要能跑起来。这一章我把从零启动到部署上线的完整链路，以及那些最容易被忽略的坑集中说一下。
6.1 本地启动完整流程
标准步骤就是六件事，按顺序做基本都能跑通：
- 创建数据库，执行源码里的SQL初始化脚本，确认表结构和初始数据都完整。
- 修改后端application.yml里的数据库地址、用户名、密码。
- 启动后端项目，确认端口正常，控制台无红色报错。
- 进入前端目录，执行npm install安装依赖。
- 执行npm run serve启动前端开发服务器。
- 浏览器访问前端地址，用初始化账号登录。
如果启动过程报错，先别乱动代码，优先排查环境版本和配置文件。特别是MySQL8.0以上，JDBC驱动类要改成com.mysql.cj.jdbc.Driver，URL里要加serverTimezone=Asia/Shanghai，否则时区报错会直接挡住启动。
6.2 部署上线关键配置
本地跑通之后，部署到服务器是另一套玩法。后端用Maven打成可执行jar包：
mvn clean package -DskipTests java -jar target/system.jar前端打包生成dist目录，由Nginx托管静态文件，并配置反向代理把/api开头的请求转发到后端服务：
server { listen 80; location / { root /var/www/dist; index index.html; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; } }try_files那行非常重要。Vue路由如果用了history模式，刷新某个子页面时Nginx直接返回404，加了这行配置才能把请求回退到index.html。这个问题几乎每个人都会遇到一次。
6.3 常见故障自查清单
下面的表格可以直接收藏，遇到问题照着排查。
| 现象 | 可能原因 | 排查动作 |
|---|---|---|
| 中文乱码 | 数据库连接参数缺字符集 | URL加characterEncoding=utf8 |
| 端口被占用 | 上一次服务没有关闭 | 确认端口或修改server.port |
| Mapper接口找不到 | 没加@MapperScan | 启动类或配置类扫描Mapper包 |
| mapper.xml不生效 | 打包时XML未进classpath | pom.xml增加资源过滤配置 |
| LocalDateTime返回格式异常 | Jackson序列化未配置 | 配置日期格式或加全局配置类 |
| 前端页面刷新404 | 路由history模式+Nginx未配try_files | 补上try_files配置 |
| 接口跨域 | 前后端端口不一致 | 开发用proxy，生产用Nginx转发 |
| 分页参数失效 | PageHelper版本或方言问题 | 确认依赖版本和数据库类型 |
| 重新导入已删学号报冲突 | 逻辑删除仍占用唯一索引 | 结合业务调整删除策略 |
| 密码校验失败 | BCrypt加密方式不一致 | 确认初始化数据的密码加密方式 |
这张表里的每一项，都是我反复看类似项目源码时总结出来的高频问题。不要等到生产环境才去关注，本地启动阶段就应该按这个清单过一遍。
6.4 源码阅读与二次开发的正确姿势
最后聊聊拿到这套完整源码后，怎么读效率最高。
我的建议是“跑通 -> 找骨架 -> 画闭环 -> 再动手”。先启动项目，注册一个测试学生、一个测试教师、一个管理员，把每个角色页面点一遍，记录哪些页面和预期不符。然后从数据库表出发，按“实体类 -> Mapper接口 -> XML -> Service -> Controller -> Vue API模块 -> 页面组件”这条链路去读，你会发现每个功能都能形成一个完整闭环。
做二次开发时，新增一个模块的基本套路是固定的：建表、写实体、写Mapper、写Service、写Controller、写前端页面、配路由。比如给系统增加课程评价功能，就是照着课程模块的代码走一遍，再把评价表和选课表关联起来。
我一直保持的习惯是：先备份数据库，通读SQL初始化脚本，尤其是管理员初始账号的密码加密方式。然后跑通全流程，再动代码。这个习惯帮我避开了很多“改了前端却不知道后端字段对应不起来”的低级问题。教学管理系统这类项目，业务不复杂，但涉及的角色和流程是完整的，把它彻底吃透，收获会比你想象中大很多。
