SpringBoot+Vue 这个组合，在国内做毕设和课设的圈子里几乎快成“默认选项”了。我见过太多人拿着类似的题目来问，要么是系统跑不起来，要么是跑起来了但一问三不知，答辩的时候被老师追问几句就卡壳。这篇博文我就拿“在线课程管理系统”这个最典型的全栈项目，把从需求拆解到前后端联调、再到部署答辩的完整链路完整捋一遍，包含了我自己实际开发中踩过的坑、总结的经验，以及哪些地方可以快速加分。
1. 项目整体设计与思路拆解
1.1 为什么这套技术栈成了“标配”
先说一个很多初学者没搞清楚的事情：你选SpringBoot+Vue，到底是在选什么？
表面上看，SpringBoot负责提供接口，Vue负责渲染页面，MySQL负责存数据，三者各司其职。但往深了说，这套组合真正的价值在于它天然就是“前后端分离”架构的教科书级范例。
后端不关心页面长什么样，前端不关心数据存在哪里，两边只通过JSON格式的接口通信。这个思路一旦建立起来，你以后接手任何企业级项目都不会懵，因为目前主流互联网公司的开发模式基本就是这个路子。
再往具体了说：
- SpringBoot解决了Java后端开发中配置繁琐的问题。以前写SSM（Spring+SpringMVC+MyBatis）要配一大堆XML文件，现在SpringBoot通过自动配置和起步依赖，把大部分样板代码直接省掉了。你只需要关注业务逻辑本身。
- Vue是渐进式JavaScript框架，对于课设级别的系统，你不需要掌握全部原理，只要会用组件化开发、路由、状态管理，就足够做出一个交互流畅的页面。
- MySQL则是关系型数据库里的常青树，免费、稳定、资料多，出任何问题都能在网上找到解决方案。
这套组合尤其适合没有太多项目经验的学生，因为每一个环节你都能找到海量的参考案例和学习资料，不太容易卡死在某个冷门问题上。
1.2 功能模块拆解：你需要面对的真实需求
在线课程管理系统，听起来好像很简单，就是“管理课程”而已。但如果你真的直接上手写代码，会发现需求边界非常模糊。我习惯的做法是先画角色，再定功能。这个系统至少涉及三类角色，而每一类角色想要的东西完全不一样：
| 角色 | 核心诉求 | 典型操作 |
|---|---|---|
| 学生 | 找课、选课、上课、交作业 | 浏览课程列表、选课/退选、在线观看课程资料、提交作业、查看成绩 |
| 教师 | 发布课程、管理学生、批改作业 | 创建课程、维护课程章节资料、查看选课学生列表、发布作业并评分 |
| 管理员 | 管人、管课、管全局 | 用户管理（启用/禁用）、课程审核、公告发布、数据统计 |
这一个表格列出来，你才发现事情并不简单。学生要看课、要选课、要做作业；教师要建课、要传资料、要批作业；管理员还要对整站内容负责。三者叠加起来，基本就是一个缩小版的在线教育平台。
我建议你千万不要一上来就埋头写代码，先去拿一张纸，把这三类角色各自能干什么列出来，然后再把功能落成页面和接口。这个过程通俗讲就叫“需求分析”，很多同学忽略这一步，结果写着写着发现漏了一个重要页面，回过头来改表结构，痛苦加倍。
1.3 技术架构选择一个清晰的理解方式
这个项目的整体调用关系，我用大白话给你描述一遍：
浏览器里的Vue页面发起请求，请求通过Axios发出，SpringBoot后端的Controller接收请求，然后调用Service层处理业务逻辑，Service层再调用Mapper层去操作MySQL数据库，数据返回后逐层倒回去，最终以JSON格式给前端，前端渲染成你看到的页面。
这里面有个容易被忽视的点：前端和后端代码是两个完全独立的工程，它们之间没有任何直接依赖。开发时可以同时进行，需要调试时只需要保证接口契约一致即可。
在实际操作中，我会把接口文档直接列在项目ReadMe里，例如“课程列表接口：GET /api/course/list，参数：无，返回：课程数组”。前后端各干各的，联调时再统一对接，效率非常高。
2. 数据库设计与核心后端逻辑
2.1 表结构怎么设计才合理
在线课程管理系统的数据库设计，说难不难，但有几个地方特别容易出错。我先给出一套经过验证的表结构方案，你看看它的设计思路：
第一张表是用户表，也就是user表。这张表里除了常规的username、password之外，一定要有一个role字段，用来区分学生、教师、管理员三种角色。密码不要存明文，用BCrypt加密存hash值。
第二张表是课程表，也就是course表。字段包括课程名称、课程简介、教师ID（外键关联用户表）、封面图URL、分类、选课人数上限、创建时间。注意，这里要有一个status字段，用来表示课程是“上架”状态还是“下架”状态。
第三张表是选课关系表，也就是course_selection表。它记录了哪个学生选了什么课、什么时候选的。这里要注意设置联合唯一索引（student_id + course_id），防止一个学生重复选同一门课。
第四张表和第五张表分别是章节表和作业表。章节表挂在某个课程下面，存放课程视频或图文资料的链接；作业表也挂在课程下面，但关联的是学生提交的内容和教师给的分数。
设计完这套表结构，你会有一种很明显的感觉：整个系统的骨架已经出来了，后面所有代码都是围绕这些表在“增删改查”。好的数据库设计能让你的开发过程事半功倍；设计得不好，后面写代码就会到处别扭。
2.2 权限控制：学生的“门禁卡”
课程管理系统最核心的后端技术点，不是什么高深算法，而是权限控制。
一个学生不能去调用“创建课程”的接口，一个教师不能去修改另一个教师的课程信息。要实现这个，最常见的方案是：登录接口成功以后，后端用JWT（JSON Web Token）生成一个带用户ID和角色信息的令牌返回给前端；前端把令牌存在localStorage里；之后每次请求都在HTTP请求头里带上这个令牌；后端写一个拦截器，拦截所有需要登录才能访问的接口，校验令牌是否有效、是否过期。
我在实际写这个功能时用的是SpringBoot的HandlerInterceptor + JWT。步骤很简单：
- 定义一个JwtUtil工具类，负责生成和解析令牌。
- 定义一个AuthInterceptor拦截器，在preHandle方法里取出请求头的token，解析成功就放行，失败就返回401。
- 注册拦截器，配置好哪些路径需要拦截，哪些路径放行。
需要注意的是，登录接口、注册接口、课程列表这种公开页面是不能拦截的，你需要在拦截器配置中把这些路径单独排除掉。很多新手在这个地方踩坑，配完了拦截器以后登录接口也调不通了，就是这个原因。
2.3 后端分层的写法与避坑
SpringBoot后端项目，我强烈建议你按Controller、Service、Mapper三层来组织代码。
Controller层负责接收前端请求、参数校验、调用Service、返回统一格式的结果。Service层负责业务逻辑，比如选课的时候要查一下课程是否已满、学生是否已经选过。Mapper层就是纯粹的数据库操作。
有一个看起来很小但能大幅度节省你时间的技巧：把所有接口的返回值都封装成一个统一的Result类，结构是code（状态码）、msg（提示信息）、data（数据）。比如成功就返回code=200，失败就返回code=500。前端所有请求都按这个约定来解析，配合Axios的响应拦截器，代码会非常清爽。
还有一个细节是异常处理。不要在每个接口里都写try-catch，直接在项目里加一个@RestControllerAdvice全局异常处理器，把业务异常和系统异常统一拦截，再转成对应的Result结构返回给前端。前端拿到的永远是结构一致的数据，这是企业级开发很常见的做法，放在课设里就是妥妥的加分项。
2.4 数据库连接与MyBatis-Plus的加速技巧
在写数据库访问层的时候，如果你用的是MyBatis-Plus这个增强工具包，你的代码量至少能减少一半。MyBatis-Plus的BaseMapper内置了常见的增删改查方法，你甚至不需要手写SQL就能完成大部分操作。
举几个例子：
- 查询所有课程：直接调用courseMapper.selectList(null)
- 按ID查询：courseMapper.selectById(1)
- 条件查询：用LambdaQueryWrapper构造条件，比如查询“已上架且分类是Java”的课程
不过有一点要提醒你，如果查询逻辑比较复杂，比如多表联查，建议还是老老实实写SQL注解。MyBatis-Plus并不是万能的，把复杂查询用注解方式写在Mapper接口上，可读性反而更高。
数据库连接方面有个经典坑：MySQL 8.x版本的驱动类名是com.mysql.cj.jdbc.Driver，而MySQL 5.x是com.mysql.jdbc.Driver，如果你用了新版数据库却沿用了旧驱动名，项目直接启动报错。另外连接URL里要记得加上serverTimezone=Asia/Shanghai，解决时区问题。
3. 前端Vue实现与前后端对接
3.1 从零搭建Vue项目的合理姿势
前端部分我推荐直接使用Vue CLI或者Vite来初始化项目。对于课设级别的系统，用Vite搭Vue 3项目是目前比较主流的选择，启动速度快，配置也更简单。
初始化完成以后，你需要安装几个核心依赖：Vue Router（路由）、Pinia或Vuex（状态管理）、Axios（HTTP请求库）、Element Plus（组件库）。
Element Plus是阿里的Vue 3组件库，里面有现成的表格、表单、弹窗、菜单组件，长得也够专业。做管理后台类系统，用组件库能节省大量写CSS的时间，也让页面效果看起来像模像样。
3.2 路由守卫与状态管理：让页面“认人”
前端要做好两件事：页面跳转和登录状态保持。
路由守卫是一个很重要的概念。通俗点说，就是当你在浏览器里直接输入某个页面的URL时，前端需要先判断一下“这个人到底有没有登录？他有没有权限进这个页面？”如果没有，就强制跳转到登录页。这部分在Vue Router里用beforeEach钩子实现。
状态管理方面，我的习惯是用Pinia在内存中存储当前登录用户的个人信息，比如用户ID、用户名、角色。这样在任何组件里都能方便地拿到“我是谁”，从而决定页面上显示哪些按钮和功能。
3.3 Axios封装与接口调用的统一套路
不要在每个页面里都直接写一长串Axios请求代码，那样后期维护会很痛苦。你应该在项目里先封装一个request.js文件：
）创建Axios实例，设置基础URL指向后端地址。2）在请求拦截器里，每次请求都从localStorage取出token并加到请求头。3）在响应拦截器里，统一处理后端返回的code：code为200就直接返回数据；code为401就说明登录过期，跳转到登录页；其他code弹出错误提示。
这样一来，你在业务页面里只需要写：
const res = await request.get('/api/course/list')页面里的逻辑就只剩下“拿到数据然后渲染”，错误处理已经在拦截器里统一完成了。
3.4 核心页面的实现思路与关键取舍
前端主要页面有登录页、首页、课程列表页、课程详情页、教师管理后台、管理员后台等。
登录页的设计比较常规，表单加上一个登录按钮，提交后调用后端登录接口，拿到token后存起来，然后根据角色跳转到不同的首页。
课程列表页用Element Plus的卡片布局来展示课程封面、名称、简介和选课按钮。如果是学生角色，按钮显示“选课”；如果是教师角色，按钮显示“编辑”和“删除”。不同角色看到不同操作，这在前端实现上就是一个v-if判断的事。
课程详情页要展示课程章节列表和作业列表，这个页面的数据来源有两个接口，章节接口和作业接口，可以用Promise.all同时请求，减少等待时间。
有一个比较细节的地方是上传功能。比如教师上传课程封面、上传课件文件，你需要用Element Plus的上传组件，并且配置好action为后端的文件上传接口。SpringBoot处理文件上传用MultipartFile接收即可，需要设置配置文件里的最大上传大小限制。
3.5 联调阶段最容易碰到的三个问题
前后端联调是整个项目里最容易卡壳的阶段，而且卡壳的原因往往特别简单。
最典型的是跨域问题。浏览器出于安全考虑，默认不允许从一个端口去访问另一个端口的接口。比如前端在8080端口，后端在8081端口，前端去请求后端就是跨域。解决办法在后端加一个CORS配置类，允许指定源头访问。我用的是WebMvcConfigurer重写addCorsMappings方法，开发时允许所有源头，上线后再收紧。
第二个典型问题是日期格式。后端返回的时间是Java的LocalDateTime，默认序列化成“2025-07-04T12:00:00”，前端显示很别扭。解决方式是统一在配置里设置日期格式为“yyyy-MM-dd HH:mm:ss”，让时间变得可读。
第三个是接口协议不一致。前端定义请求参数用驼峰命名比如courseName，后端实体类字段也应该是courseName。如果两边风格不统一，数据就会对不上，这种问题排查起来极其费神，最好的办法是在开发前就把接口文档定清楚，或者用Swagger自动生成接口文档，两边一起看。
4. 整个项目全流程实战记录
4.1 从零到跑通：我用的一天时间流程
我用一个完整的时间线，给你演示一下如果是一个有一定基础的同学，按照合理顺序去开发这个系统，一天下来能走到哪一步：
上午8点到10点：搭建后端工程，配置数据库连接，编写用户表、课程表、选课表的实体类和Mapper，测试用户注册和登录接口，跑通JWT生成。
上午10点到12点：写完课程相关的增删改查接口，包括课程列表、课程详情、创建课程、更新课程、删除课程。同时把选课和退选接口也搞定。
下午2点到4点：搭建前端工程，配置路由和Axios，完成登录页面和课程列表页面。
下午4点到6点：把前端管理后台做起来，包括教师创建课程的表单、管理员管理用户的表格。
晚上8点到10点：前后端联调，修复跨域和字段不一致的问题。
你看，一天时间是完全可以完成一个“能演示”的版本。但如果你想做到答辩游刃有余，这就需要再花两三天去打磨细节了，比如表单校验、按钮loading状态、空数据提示、异常情况处理等。
4.2 实践过程中我从踩坑到加分的记录
我印象很深的一次经历是，数据库密码配置文件里用了明文，结果项目提交到Git仓库以后被同学看到，虽然不是什么大不了的事情，但很尴尬。后来我学乖了，配置文件里用占位符+本地环境变量管理敏感信息，这个小习惯被某位导师夸过“有工程意识”。
另外有一次我在做“选课人数限制”功能时，逻辑是先查询当前选课人数，小于上限就插入选课记录。看起来没毛病，但高并发下会超选。我当时没考虑并发问题，但在答辩时老师恰好问到“如果一百个人同时选最后一门课怎么办”，我答不上来。后来我改成在插入前用数据库条件更新加distinct统计的方式处理，虽然性能一般，但课设答辩时能讲出这个思考过程，反而变成了加分点。
4.3 项目部署与展示的稳妥方案
课设和毕设最终都要演示，你至少得让系统能在本地跑起来。但如果你想让效果更好，可以考虑部署到云服务器上。
部署的基本流程是：
后端部分，用Maven打包成jar包，然后在服务器上安装JDK环境，用java -jar命令启动，搭配nohup后台运行。
前端部分，先执行npm run build打包出静态文件（dist目录），然后用Nginx托管这个目录，再配置一个反向代理，把/api路径的请求转发到后端的端口。
这里有个很容易忽略的问题：Nginx配置反向代理时没设置proxy_set_header，后端通过request.getHeader("Authorization")取不到token，接口全部401。你的配置里一定要加上请求头转发。
5. 常见问题梳理与快速排查参考
5.1 按错误现象排查
| 现象 | 可能原因 | 解决办法 |
|---|---|---|
| 后端启动报错，提示数据库连接失败 | 数据库没启动、密码错误、驱动名不对 | 检查MySQL服务、核对账号密码、确认驱动名 |
| 前端请求接口报404 | 后端路径没对上、前端请求URL写错 | 核对接口文档里的完整路径 |
| 前端请求接口报500 | 后端代码异常了，通常是空指针或SQL问题 | 看后端控制台日志定位具体行号 |
| 登录后请求接口报401 | token没带上、token过期、拦截器放行路径不对 | 检查请求头、重新登录、检查拦截器配置 |
| 中文乱码 | 数据库编码不是utf8mb4，或连接URL没指定编码 | 建库时指定utf8mb4，连接URL加characterEncoding=utf8 |
| 前端页面白屏，控制台报错 | Vue组件引入路径错误、依赖版本冲突 | 检查import路径、查看是否缺少依赖 |
5.2 逻辑排查的典型场景与建议
有一个逻辑问题很典型：前端页面明明显示了“选课成功”，刷新以后课程列表里的状态却没有变化。排查了半天才发现，原来是后端选课成功后返回成功，但前端的“已选课状态”是在页面加载时查一次，选完以后没有重新拉取接口更新状态。解决办法就是选课成功以后，重新请求一次课程列表数据。
还有一个经验是：项目写到一半，千万不要图方便，把所有逻辑都写在Controller里。一旦功能多起来，Controller会变成一个大杂烩，后面前端对接、后期维护都会特别痛苦。坚持三层架构，哪怕每个Service方法一开始只有一行调用Mapper的代码，也先把架子搭好。
6. 扩展思路：如何把课设项目做出亮点
6.1 “我只是个课设”不代表可以不做细节
很多同学觉得课设项目嘛，功能能跑就行，但答辩分数往往是靠细节拉开的。
比如表单校验这块，一个合格的项目在用户提交空表单、输入非法邮箱、选择超范围日期时，都需要有对应的提示。直接在Element Plus里配置rules规则，花不了多少时间，但演示效果天差地别。
再比如按钮的loading状态，点击“确认选课”以后，按钮应该变成不可点击并转圈，等接口返回后再恢复。这个细节很多同学不做，但做了以后给人的感觉就是“这个系统是真的能用的”，而不是“教学演示品”。
6.2 功能扩展的好方向
如果你时间充裕，以下几个方向能让项目上一个台阶。
第一个是接入Redis。在登录时把token存入Redis并设置过期时间，退出登录时主动删除。这个改动不大，但可以理直气壮地在论文或答辩里写上“引入缓存，提高系统并发处理能力”。
第二个是增加数据统计功能。管理员页面用图表展示每天新增用户数、最热门的课程排名、选课人数趋势。Vue里面可以用ECharts图表库，后端加一个统计接口，用GROUP BY语句查询即可。
第三个是增加文件批量导入功能。比如教师通过Excel批量导入学生名单，后端用EasyExcel解析，前端用上传组件。这种功能在企业系统中非常常见，放在课设里也显得项目很完整。
6.3 写在最后的实用建议
根据我带过的很多做课设的同学的经验，最稳妥的做法是：
先花半天把需求想清楚，再花一天把数据库表和后端接口写完，再花一天把前端页面全部跑通，最后留一天时间做细节打磨和演示排练。
不要一开始就纠结“用什么图标库”“按钮颜色好不好看”，这些是最后做的事。先把核心链路跑通，再回头补细节。
说到底，这个系统并不难，难的是你愿不愿意静下心来，老老实实把每一个模块都理清楚，把每一个报错都查明白。等你完整走完一遍这个过程，你收获的不仅仅是一个能过答辩的项目，更重要的是你真正理解了“一个Web系统是怎么从无到有跑起来的”这件事。
