每个做毕设的同学大体都会在选题阶段经历过一轮纠结题目太容易显得没技术含量题目太难又怕自己兜不住完不成代码直接挂掉。如果你正卡在这一步我建议认真考虑在线视频教育平台这类基于 Spring Boot Vue 的完整前后端分离项目。这个方向业务模型贴近真实、功能边界清晰、扩展空间充足而且“视频播放课程购买后台管理”的组合恰好是答辩时最能讲出内容的一套闭环。这篇文章我就把这个项目的技术选型、功能拆解、数据库设计、源码运行到论文答辩的完整链路全部摊开讲给准备用这个题目做毕设的你一份可直接照做的路线图。这不是让你拿网上源码一交了事的思路而是告诉你拿到一个附源码论文的项目之后应该怎么把它真正变成自己的作品怎么读懂它、跑通它、改出差异化然后在答辩现场稳得住。1. 毕业设计选题的性价比账在线教育平台凭什么值得做1.1 毕设选题到底在选什么毕业设计不是企业级项目评价它的核心标准其实是三条你自己能不能做完、论文里能不能写清楚、答辩现场能不能讲明白。复杂度和工作量要处于一个跳一跳够得着的位置太低显得敷衍太高容易翻车。在线教育平台这个题目恰好落在这个区间里。从业务上看它不涉及电商那种海量商品、复杂库存和物流链路也不涉及社交产品那种高并发消息推送核心就是课程、用户、订单、播放进度这几条主线。每一条主线的业务规则都不算复杂但它们组合在一起就构成了一套完整的、可以讲出层次的系统。从技术上看它同时覆盖了前端页面交互、后端接口开发、数据库建模、文件上传、权限校验、订单事务这些常见知识点。你在简历上写参与开发了一套在线点播平台面试官不会觉得你在夸大你在论文里写系统采用前后端分离架构实现了用户鉴权、课程管理、视频点播和订单支付功能每一句都能对应到具体代码和截图。1.2 在线教育平台的差异化空间每年做这个题目的学生不少但这不代表题目太烂大街。恰恰相反正因为大家都在做类似方向才更容易做比较。同一套Spring Boot Vue 骨架你可以把业务往职业培训、大学生技能课、中小学课外辅导、企业内部培训等不同方向偏。这个偏向后端接口可能改动不大但前端页面、课程分类、业务文案甚至论文的选题背景都会跟着变化。另一个差异化方向是功能的横向扩展。基础版的在线教育平台通常只包含课程浏览、购买、播放和后台管理如果你有余力可以往课程评论互动题库练习讲师专栏会员订阅限时优惠这些子模块上加。哪怕只多做一个模块论文里的系统创新点和功能说明顿时就有东西可写了答辩时的自我展示篇幅也更充足。选题的本质是选择一套可解释的复杂度。在线教育平台能让你解释清楚每一个功能存在的业务理由这正是毕设评分时最看重的部分。2. 技术栈的内在逻辑Spring Boot 与 Vue 为什么能撑住全栈毕设2.1 后端的稳来自 Spring Boot 的单体架构后端用Spring Boot在今天基本不需要犹豫。它内置了Tomcat打成一个Jar包就能直接跑部署和演示都很省心。对毕设来说这套特性意味着你在答辩前换一台电脑演示几乎不会遇到什么环境层面的突发问题只要装了JDK就能启动。Spring Boot 的巨大生态也是加分项。课程列表要分页筛选用 MyBatis-Plus 的分页插件几行代码就搞定文件上传要限制大小Spring Boot 的 MultipartFile 和配置项直接处理登录鉴权想做得规范一点配合 JWT 工具包也能干净落地。你大学四年学过的 Spring 相关技能在这个项目里几乎全都有自然的使用场景论文的相关技术介绍一章也顺理成章。我建议持久层框架优先选 MyBatis-Plus 而不是 Spring Data JPA。原因倒不是谁绝对更好而是国产毕设项目中使用 MyBatis-Plus 的比例极高你遇到问题能搜到的资料最多而且它自带代码生成器可以快速生成基础的单表 CRUD 代码省下来的时间可以去打磨业务流程。当然如果你对 JPA 更熟用它也完全没问题关键是不要在论文里把两个框架混着写给自己挖坑。2.2 前端的快来自 Vue 与组件化生态前端用 Vue 的原因也很直白教程多、上手快、配套的组件库成熟。毕设里最常见的后台管理界面比如课程管理、用户管理、订单管理本质上就是一堆表格、弹窗、表单和分页组件。用 Vue 配上 Element UI 这类组件库直接照着文档拼页面就行视觉上也不会太寒酸。更重要的是Vue 的组件化和响应式特性和你后端接口返回的数据结构能自然对应起来。课程列表页拿到后端返回的分页数据直接塞给表格组件就能渲染用户点击购买按钮后前端发起请求拿到订单结果后再用 Message 提示成功或失败交互链路非常顺。这种组件化开发的体验本身就是论文里一个不错的点。在系统实现部分你可以专门讲一下前端如何按页面拆分成组件、如何用 Vue Router 管理路由、如何在请求封装里统一处理 Token 和错误状态。这些内容虽然实现起来不难但写出来会让论文显得很专业。2.3 为什么不要碰微服务和安全把控另一个方向是大家容易纠结的问题既然想拔高一点要不要加上 Nacos、Ribbon、Feign 这些微服务组件我的建议很直接——不要。毕设的目的是考察你有没有独立完成一个完整系统的能力微服务引入的服务注册、服务发现、分布式事务、链路追踪每一项都会显著增加项目的复杂度和部署成本。一个 Spring Boot 单体应用如果把业务模块划分得清晰照样能在论文里讲出高内聚、低耦合的设计思想。你可以把用户服务、课程服务、订单服务作为不同的业务包来组织甚至可以在架构图上画出模块之间的调用关系。但一旦你引入了真正的微服务框架你就要在论文里直面一个灵魂问题为什么要拆拆了之后解决了什么痛点大多数毕设同学的认真回答其实是为了显得高级这个答案是经不起追问的。技术选型的安全区永远是自己能完全掌控的复杂度。Spring Boot Vue 这个组合恰好处于这个安全区的上限。3. 先业务后代码一条用户学习路径串起所有功能模块3.1 游客到学生的转化路径拿到代码之后不要急着从登录注册开始看我建议你先跟着游客视角把整条业务流程走一遍。游客进入首页能看到课程列表列表支持按分类筛选、按销量排序、分页展示点进课程详情页能看到课程简介、课时数、所属分类和价格对于免费课程或课程的试看小节游客可以直接点播放要购买付费课程或发表评论就必须注册登录。这套流程对应到后端的接口链路是课程分类接口、课程分页列表接口、课程详情接口、视频播放地址接口。你可以顺着这条线把相关 Controller 看一遍整个项目的主干结构就清楚了。注册登录环节通常采用 JWT 方案。用户在登录页提交账号密码后后端校验用户表并签发一个包含用户 id 和角色的 Token 字符串前端把它存在 LocalStorage 里之后每次请求都在 Header 里带 上 Authorization 字段。后端再用拦截器统一校验这个 Token 的有效性并根据角色判断是否有权限访问某个接口。JWT 最大的好处是天然适合前后端分离场景后端不需要维护 Session避免了跨域携带 Cookie 的麻烦。3.2 教师创建课程的上架链路第二个要理解透的角色是教师。教师登录后进入个人中心可以创建课程填写课程名称、简介、封面图、所属分类、价格创建完课程之后继续往课程里添加章节每个章节下再维护一个小节每个小节绑定一个视频地址。这个课程-章节-小节的三级结构是平台最核心的数据模型后端接口基本都围绕它展开。当教师完成课程和章节设置后课程的状态从未发布变成已上架。有的项目会有管理员审核后上架这个环节有的则直接上架这两种设计都行但你要能解释自己项目里用的是哪一种。常见的做法是教师保存的课程先处于草稿状态确认提交后直接上架简化流程因为毕设项目里基本没有真正的内容审核场景。视频的上传一般有两种实现路径一种是把视频文件传到本地磁盘的指定目录数据库只保存访问路径另一种是接入对象存储服务或云点播服务上传成功后保存云端 URL。毕设项目里前一种实现得更多因为不依赖外部资源但这部分往往是最容易出 bug 的地方后面我会单独讲。3.3 管理员的后台职责边界管理员账号对应的后台模块是很多同学在论文里写需求分析时最容易忽略的部分。管理端通常包含用户管理、课程管理、订单管理和公告管理。用户管理可以查看注册用户列表、启用或禁用某个账号课程管理可以对所有课程进行下架操作订单管理负责查看订单记录和支付流水公告管理则维护首页轮播图和系统通知。这部分逻辑本身不复杂核心就是一组增删改查 状态变更的接口。但要注意思考一个问题管理员的权限是怎么控制的如果你在项目里用了 Spring Security 或自定义拦截器做角色判断论文里就要专门写清楚管理员 Token 和普通用户 Token 的区别以及为什么管理员能访问那些普通用户不能访问的接口。如果你用的是最基础的 if 判断那也至少要让前端的路由能根据角色控制页面显示。把这三条角色链路全部梳理清楚后你会发现整个项目的代码都是围绕角色数据流组织的。这时再去看任何一段具体代码都不会有这是哪来的的迷茫感。4. 十二张核心表数据库设计直接决定论文和答辩的深度4.1 核心表清单与职责划分数据库设计是整个毕设项目的地基也是论文里系统设计一章的重头戏。一个标准的在线视频教育平台核心表大概在十到十四张左右。我按业务模块把它们分成五组下面用表格列出最常见的表名和职责方便你在拿到项目后逐一对号入座。分组表名称核心字段示例职责说明用户体系sys_userid, username, password, nickname, role_id, status存储用户账号信息密码加密保存用户体系sys_roleid, role_name, role_code定义管理员、教师、学生等角色用户体系sys_user_roleid, user_id, role_id用户与角色的关联表课程体系course_categoryid, name, parent_id, sort课程分类支持一级或两级分类课程体系course_infoid, teacher_id, category_id, title, price, cover, status, total_lesson课程主表冗余教师和分类信息课程体系course_chapterid, course_id, chapter_name, sort课程的章级结构课程体系course_lessonid, chapter_id, lesson_name, video_url, is_free, duration章下的小节绑定具体视频地址订单交易order_infoid, order_no, user_id, total_amount, status, pay_time订单主表记录支付状态订单交易order_itemid, order_id, course_id, price订单明细记录购买的具体课程学习进程learning_recordid, user_id, lesson_id, progress, update_time记录用户学到哪一课、播放到几分几秒互动内容course_commentid, user_id, course_id, content, create_time课程评论区系统运营sys_noticeid, title, content, cover, status首页公告或轮播图这个表格里的id我会统一用自增主键status字段统一用 0 或 1 表示禁用或启用。对于金额字段比如价格字段我建议直接用 decimal(10,2) 而不是 float避免后续出现金额精度问题这也是面试官比较看重的细节。4.2 容易被忽略的字段与索引设计很多人设计表的时候只关注有哪些字段但容易忽略两个隐藏问题冗余字段和联合索引。课程表里有一个 total_lesson总课时字段这个字段其实是冗余的正常情况下可以通过统计章节小表的小节数算出来。但之所以保留它是因为课程列表页要展示共 X 节课的信息如果每次都去 count 子表列表接口性能会很差而且代码也啰嗦。这种以空间换时间的冗余设计是关系型数据库里非常经典的手法你的论文数据库设计部分完全可以拿这个点来讲。学习进度表是最容易出现重复记录的典型场景。一个用户反复观看某一节课程时如果不做约束很可能每次播放就插入一行新记录导致数据混乱。正确做法是在 user_id 和 lesson_id 上建立联合唯一索引之后每次播放都走先查询、存在则更新、不存在则插入的逻辑。这个设计在答辩时非常容易被问到你可以把它当作展示自己数据库建模能力的例子。索引不是越多越好但有三个方向值得加索引课程列表的 status 和 category_id 组合索引用来支撑首页的筛选查询订单表的 user_id 索引用来查询我购买的课程分类表的 parent_id 索引用来查子分类。实际项目里的索引设计要考虑查询频率和写操作开销毕设里能做到上面这几点已经超出平均水平了。4.3 外键的去留与数据一致性关于外键约束很多项目教材里都强调外键很重要但真实的后端项目里特别是互联网项目里普遍的做法是不加物理外键只在应用层维护逻辑关系。原因是外键会带来额外的数据库检查成本在高并发写入时容易成为瓶颈也会让表之间的耦合偏高。毕设项目其实加不加外键都能说得通。关键是你必须在论文里讲清楚自己的选择。如果用了物理外键就写通过外键约束保证数据完整性如果没用外键就写在应用层对关联数据进行校验并进行逻辑删除避免物理外键带来的性能开销。这里还要注意一个和删除相关的点删除课程或用户时如果这类数据已经被订单记录关联直接把记录物理删除会导致历史数据缺失金额统计也会出错。所以毕设项目里更推荐用 status 字段做逻辑删除而不是 delete 语句。订单、课程、用户这三张表尤其要小心别在答辩演示时手动删除一个已购课程然后被问到用户购买记录怎么办时答不上来。5. 拿源码到本机跑通从解压到首页弹出的完整流程5.1 环境版本对照与初始化动作不管你从哪个渠道拿到这份源码第一步都是把基础环境对齐。我就以最常见的版本组合为例JDK 1.8、Maven 3.6、MySQL 5.7 或 8.0、Node.js 14 到 16 之间的版本。Node 版本是我特别想提醒的。Vue 2 的项目如果在 Node 17 以上运行经常会因为 openssl 的旧接口冲突报错。如果你用的是 Vue 2 模板建议装一个 Node 14 或 16 再用。这个坑几乎每届都会有人踩报错信息看着像编译错误实际上只是版本兼容问题。环境就绪后先创建数据库再把项目里带的 .sql 文件导入。导入后先别急着启动打开数据库看一遍表结构和初始数据。这一步的重点是找到各个角色对应的初始账号并确认管理员的密码确实是加密存储的。很多项目会在 README 里写默认账号比如管理员账号 admin、教师账号 teacher、学生账号 student但你也可能随手找到另一个文件里的说明总之先别跳过这一步。5.2 后端配置最容易错的两个点后端项目的配置文件一般集中在 src/main/resources/application.yml 或 application.properties。最容易出错的是两个地方数据源配置和文件上传路径。数据源配置主要是 url、username、password 三项。很多项目里的 url 会写成 localhost:3306你要确认它确实指向你本机的 MySQL 实例用户名和数据库密码更要改成自己的本机配置如果直接跑报Access denied八成就是这里没改。文件上传路径通常长这样spring: servlet: multipart: max-file-size: 1024MB max-request-size: 1024MB mvc: static-path-pattern: /** resources: static-locations: file:D:/upload/这段配置的意义是把文件上传大小限制调大并把本地磁盘的 D:/upload 目录映射成静态资源路径。如果你不做映射前端通过 http://localhost:8080/upload/xxx.jpg 之类地址访问图片和视频时就会 404。拿到源码后把路径改成你机器上的实际目录然后建好这个目录再启动后端。启动后端的命令很简单在项目根目录执行mvn spring-boot:run如果你想打包后运行可以mvn clean package -DskipTests java -jar target/xxx.jar看到 Spring Boot 启动成功的日志再确认一下端口号通常是 8080后端就算起来了。5.3 前端启动与本地跨域代理前端项目的启动分两步安装依赖和启动开发服务。依赖安装直接执行npm install如果网络环境不好可以换成淘宝镜像源速度会快很多。启动开发服务用npm run serve默认端口一般是 8081 或者 8082避免和后端端口冲突。这里有一个很关键的概念要理解透本地开发环境下前端的地址一般是 http://localhost:8081后端的接口地址是 http://localhost:8080两者不同源直接发请求必然触发跨域问题。解决方式之一是启用 Vue CLI 的 devServer.proxy 代理在前端配置文件 vue.config.js 里设置module.exports { devServer: { port: 8081, proxy: { /api: { target: http://localhost:8080, changeOrigin: true, pathRewrite: { ^/api: } } } } }这段配置的意思是前端发往 /api 开头的请求会被开发服务器代理转发到后端的 8080 端口。后端接口如果本来就有 /api 前缀那么 pathRewrite 那行就不需要如果没有就需要把这层前缀剥掉让后端能正确识别路由。理解了这个机制你就知道为什么很多前端项目的请求路径都要带 /api 前缀了。5.4 接手源码后的改名清单把项目跑起来只是第一步。如果你想拿这套源码作为毕业设计有一个容易被忽视但非常重要的问题不要原封不动提交。所有正规高校的论文检测和查重都会对代码、题目和系统名称有一定的关注度如果全班同学交上去的系统还叫同一个默认项目名基本等于给自己惹麻烦。我建议拿到源码后做三件事。第一全局搜索项目里出现的旧工程名把前端展示的网站标题、登录页 title、后端项目的 name 全部改掉。第二把后端 Maven 的 groupId、artifactId 和包名改成自己的命名方式比如改成包含你学号或姓名拼音的包名这一步虽然有点繁琐但能让项目从内到外都更像是你自己的。第三在论文的系统设计部分把这个平台的业务背景和功能细节写得贴合你的具体题目而不是泛泛的在线视频教育平台六个字。这套改名清单不是教你抄袭而是提醒你一个二开的作品能不能变成自己的作品核心看你有没有真正理解并重构过它的关键部分。哪怕只改了包名和界面文案你对这个项目的掌控感也会完全不同。6. 论文不是抄出来的结构与截图要跟着真实代码走6.1 论文目录与代码模块的映射关系不论是哪个学校的毕业论文大体都会要求这样几个大章节绪论、相关技术介绍、需求分析、系统设计、系统实现、系统测试、总结与展望。很多人写论文的问题是技术介绍写一大堆没用过的东西比如明明没做分布式技术介绍里却写了一整章微服务。论文内容一定要和你项目里真实用到的技术严格对应这是最基本的底线。我建议你按下面这个方式去对应论文和代码需求分析里的每个功能用例对应你系统里的一个前端页面和一个后端接口系统设计里的架构图对应项目里 Controller、Service、Mapper 的三层包结构系统实现里的每个流程图和截图对应你实际启动项目后点出来的页面系统测试里的每个测试用例对应你在数据库里能查到的那条真实记录。按这种映射关系写出来的论文你在答辩时随便被问到哪一段都能迅速定位到实际代码和操作步骤。反之如果你论文写的是网上拼来的内容现场演示时根本调不出对应功能那基本就没有翻盘机会了。6.2 截图和测试数据怎么准备才显得真实论文的截图部分是很多人的短板。常见的错误有截图分辨率不统一、页面数据全是默认的假数据、截图上明显还带着源码项目自带的示例课程名。这些细节在答辩老师那里一眼就能看出来。截图至少要准备三组第一组是系统全景图包括登录页、首页、课程列表页、课程详情页、个人中心展示系统整体的页面风格第二组是核心操作过程的截图包括教师添加章节、上传视频、管理员下架课程、学生购买课程并支付成功这些关键动作第三组是程序运行过程截图包括后端控制台启动日志、数据库表结构或查询结果的截图。第三组往往能加分因为很多同学只放页面截图而你把数据库后台也展示出来说明系统是真实跑通的。测试数据也不要直接用源码里的示例数据。建议你自己录入一批和论文题目场景一致的课程、用户和订单数据比如按职业课程考试培训兴趣爱好分类准备十几个不同的课程让列表页分页和筛选的效果能被直观看到。数据要前后一致课程价格、订单金额、学习进度这些字段要能自洽。6.3 答辩追问中最常见的五个问题答辩环节是毕设的临门一脚有些问题几乎是必问的。提前把这些问题准备好答案比任何临场发挥都可靠。第一个问题系统为什么用 JWT 不用 Session答案核心是前后端分离架构下后端无状态化更合适Token 由前端保存和传递天然支持跨域也便于扩展。第二个问题用户购买的课程怎么控制播放权限你的答案要落到数据库层面下单成功后才往订单表写入记录播放器在请求视频地址时后端先校验该用户是否存在有效订单或者该小节是否标记为免费。第三个问题数据库是怎么设计的为什么这么多表这时候把你论文里的数据库设计图拿过来按用户、课程、订单、进度几大模块讲一遍就行。第四个问题如果用户重复购买同一门课怎么办答案是在订单表对 user_id 和 course_id 做唯一索引或在下单前做一次校验防止重复订单。第五个问题你的密码是怎么保存的如果发现项目里存的是纯明文你要么改代码用 BCrypt 加密要么提前想好怎么解释。我的建议是直接改不要在这个问题上冒险。这些问题全部答上来之后答辩老师会发现你不仅会抄代码还真的知道这套系统内部是怎么运作的。7. 二开最容易翻车的三件事跨域、上传与订单事务7.1 CORS 跨域第一次联调必报的那个错你在本地启动前后端之后第一个遇到的报错大概率是浏览器控制台里的一串红字大意是 Access to XMLHttpRequest at http://localhost:8080/api/xxx from origin http://localhost:8081 has been blocked by CORS policy。这个问题的本质是浏览器的同源策略拦截了跨域请求。虽然前端代理能解决大部分开发环境的问题但如果你在后端直接配置了允许跨域或者在部署时用的是 Nginx 转发问题就不一样了。最稳妥的做法是在后端加一个全局跨域配置这样无论是开发还是测试环境接口都不容易被卡住Configuration public class CorsConfig { Bean public CorsFilter corsFilter() { CorsConfiguration config new CorsConfiguration(); config.addAllowedHeader(*); config.addAllowedMethod(*); config.addAllowedOriginPattern(*); config.setAllowCredentials(true); UrlBasedCorsConfigurationSource source new UrlBasedCorsConfigurationSource(); source.registerCorsConfiguration(/**, config); return new CorsFilter(source); } }这里要注意addAllowedOrigin(*)和setAllowCredentials(true)同时使用时某些版本会存在问题所以现在更推荐用addAllowedOriginPattern(*)。你把这个配置放好后跨域报错通常就消失了。7.2 视频上传Spring Boot 默认 1MB 限制的真相另一个高频翻车点就是视频上传失败。Spring Boot 的 Servlet 容器默认对单个文件限制为 1MB超过就直接抛异常很多同学在这上面困惑很久。解决方法就是前面提到的在配置里把 multipart 的限制放大。但还有一个隐藏细节如果你只改了 max-file-size 而没改 max-request-size有些场景下仍然会报错因为一次请求的总大小包含多个文件和参数两者要同时放大。文件上传成功后数据库里保存的字段一般是 /upload/video/xxx.mp4 这种相对路径。浏览器要能正常播放就要保证这个路径能被后端映射成静态资源。静态资源映射不仅影响视频也影响课程封面的图片。做完上传功能后我建议你专门验证一次上传的视频是否真的能通过 URL 直接打开因为有时候文件存进去了但访问路径配错播放器就一直是加载失败的状态。视频格式也是一个值得留意的点。浏览器播放 mp4 格式最省事但如果你上传的是 mov、avi 这类格式浏览器组件很可能不支持直接播放。为了毕设演示顺利我建议你提前用格式工具把测试视频转成 H.264 编码的标准 mp4这样在 Chrome 里任何用户点开都能直接播放。这个细节我踩过坑提前准备好能省很多事。7.3 订单与支付不加锁就等着超卖订单和支付是另一个容易在答辩时暴露问题的模块。学生点击购买按钮后后端要做的事情不止是生成订单还包括校验课程是否存在、校验用户是否已经买过、校验课程是否为免费课最后才创建订单并返回支付参数。很多毕设项目里的支付都是模拟实现的不会真的对接第三方支付接口而是用一个模拟支付页面点一下确认支付就把订单状态改成已支付。这完全没问题但你心里要清楚整个模拟过程发生了什么支付成功后系统需要同时更新订单状态和给用户开通课程权限这两件事如果中间有一个失败就会出现钱付了但课程没开通的脏数据。解决这个问题的标准做法是在业务方法上加上事务注解Transactional(rollbackFor Exception.class) public void payOrder(Long orderId) { // 1. 更新订单状态为已支付 // 2. 写入订单明细 // 3. 给用户开通课程权限写入或更新学习记录表 }还要考虑一个问题同一个用户快速点击两次立即购买后端会不会生成两张订单最有效的兜底方案是给订单表加 user_id course_id 的唯一索引或者在创建订单前先做一次校验。加了唯一索引之后哪怕前端页面有 bug 导致重复请求数据库层面也能拦住重复订单。7.4 后端的权限校验不能只靠隐藏按钮最后一个隐蔽的大坑就是权限校验不彻底。很多前端代码会通过角色判断隐藏课程管理用户管理这些入口让普通用户看不到按钮。但浏览器地址栏是可以直接输入路径的用户完全可以跳过前端页面直接向后端接口发起请求。所以后端的接口必须有独立的权限校验。常见的实现方式有几种在拦截器里对带 /admin 开头的路径判断角色在方法上通过自定义注解标记需要教师或管理员权限或者更规范一点集成 Spring Security 做统一过滤。如果你用的是拦截器方案核心逻辑通常是这样Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token request.getHeader(Authorization); if (token null || !jwtUtil.verifyToken(token)) { response.setStatus(401); return false; } // 进一步从 Token 里解析角色并判断权限 return true; }要注意的是拦截器放行的路径一定要仔细设置比如登录接口、注册接口、首页课程列表接口应该放行但用户管理接口、订单支付接口必须拦截。这个配置决定了很多细小的权限漏洞。改完以后你可以用浏览器的无痕模式打开一个用户页面直接访问一个管理员接口验证它是否真的会被拦下来。密码存储也是权限体系的一部分。有些源码里的用户密码是明文存在数据库里的这在实际的安全意识里是绝对不合格的。用 BCrypt 对密码做加密并不可怕改起来也不难关键是改完之后你要重新生成几个测试账号的密码密文否则原账号就登不进去了。这一点也常见我就不展开讲了。回头再看看整个项目从技术选型到数据库建模从源码运行到论文答辩每一步都有明确的决策理由。我见过很多同学把源码跑通后就以为万事大吉结果答辩的时候被一句你的项目核心表有哪些问得哑口无言。实际上这个项目能不能变成你自己的不取决于你改了多少代码而取决于你有没有把业务链路、数据结构、权限控制这些底层东西彻底吃透。最后分享一个实操小建议在答辩前把控制台启动过程、数据库核心表结构、一个完整的购买流程三个部分分别截图整理成一个文档然后对着文档从头到尾自己讲一遍。你会发现能顺利讲完那一刻你才真正准备好了。