NC附件上传的本地保存与OSS上传架构设计
2026/10/16 0:34:01
又到了毕业设计季。每年这个时候，后台就会涌进来大量类似的问题：Java方向选什么题目好？在线教育系统这个题有没有现成的完整方案？论文和PPT到底应该怎么搭？你点进这篇文章，大概率也是在为“基于Java的在线教育系统”这个题目做功课。说实话，这个题确实被很多学生选，但它从来不是那种随便应付就能通过的题——它天然包含了一整个业务闭环：学生注册登录、课程浏览、下单购买、视频在线学习、后台数据统计，无论单拉哪一个环节出来，都有足够的技术点可以写。这篇文章我就结合自己带过的项目经验，把一个完整的在线教育系统从需求拆解、技术选型、核心实现，到论文框架、答辩PPT、演示视频的整套思路，尽量掰开揉碎讲一遍。
我默认你是这样一个情况：有Java基础，会Spring Boot的基础用法，但还没有独立开发过一个完整的系统，也不太知道论文该写多少字、PPT该放什么、演示视频该怎么录。没关系，这些内容我会按顺序一步步过，你不需要再到处“东拼西凑”找资料，这一篇就够你撑起整个毕设。
1. 这个选题为什么值得做：先把业务需求彻底拆清楚
1.1 在线教育系统作为毕设的独特优势
很多人选题目的时候有个误区，觉得越“简单”越好，于是选那种“图书管理系统”“学生信息管理系统”。这类题目确实容易做，但也意味着你答辩的时候几乎没什么可讲的，评委一眼看穿工作量。在线教育系统不一样，它表面上是个“业务系统”，实际上把电商、内容管理、视频资源、支付交易都揉在了一起，属于典型的“麻雀虽小，五脏俱全”型项目。
从评分角度看，一个好的毕设项目通常看三点：第一是业务复杂度是否支撑得起一篇合格论文，第二是技术选型是否合理并能说清楚为什么选，第三是能否完整演示出核心流程。在线教育系统在这三点上都很占便宜。你可以只做一个常规版本，也能拿一个中等偏上的分数；如果你愿意再加一点分布式缓存、异步消息或者支付回调模拟，那就有非常多的内容可以写进论文“创新点”里了。
1.2 三种角色与权限梳理：先画清楚谁用什么功能
做系统设计的第一步永远是理清角色，角色不清，后面所有功能都是糊涂账。在线教育系统至少要拆出三种角色：学生、讲师、管理员。职称可能不同，但职责基本是这样：
| 角色 | 核心职责 | 主要操作权限 |
|---|---|---|
| 学生 | 平台内容消费者 | 注册登录、浏览课程、收藏课程、购买下单、观看已购视频、评价课程、查看个人学习记录 |
| 讲师 | 平台内容生产者 | 登录、维护个人课程、上传视频、查看课程购买与学习数据、申请课程上架 |
| 管理员 | 平台运营管理者 | 用户管理、讲师审核、课程上下架、订单管理、数据统计、分类管理 |
这里要特别提醒：很多学生会把讲师和管理员的权限混在一起，结果就是后台页面什么都能干，答辩被问“你如何控制用户越权”时答不上来。正确做法是在设计阶段就用“权限矩阵”把每个角色的操作列清楚，代码里用统一的鉴权逻辑去控制，这样论文的需求分析章节也有清晰可写的素材。
1.3 核心业务链路：一个用户从进入平台到完成学习的完整闭环
单说功能列表很空，你得把“业务流程”串起来。我建议你按一条主线去设计整个系统：注册登录 → 浏览课程列表 → 查看课程详情 → 下单购买 → 模拟支付成功 → 课程解锁 → 观看章节视频 → 发表学习评价。这条链路就叫“核心闭环”，论文里画用例图、业务流程图，都围绕这条线来，评委一看就懂。
在这条链路里，有几个关键状态必须提前定义好，不然写代码到一半会各种乱：课程状态可以设计为“待审核—已上架—已下架”，讲师发布课程后不能立刻展示，要等管理员审核；订单状态可以设计为“待支付—已支付—已取消”，模拟支付回调成功后才会从待支付切到已支付；用户购买记录要单独存一张表，避免重复购买同一门课。这些状态机的设计，是你论文“系统设计”部分最值钱的内容。
2. 技术栈选型与总体架构设计：不盲从、不炫技
2.1 为什么这个组合是Java毕设里的“稳妥标配”
我跟很多学生交流过，最常见的问题就是“技术选型到底听谁的”。有人说用SSH（Struts+Spring+Hibernate），有人说用Spring Cloud微服务，还有人直接说“网上视频教啥我就用啥”。我的观点是：技术选型必须结合三点来考虑——你的熟练程度、系统的实际规模、答辩时能不能把来龙去脉说清楚。
对于在线教育系统这种规模，最稳妥的组合是：后端Spring Boot + MyBatis Plus + MySQL + Redis，前端独立工程用Vue（或配套的后台管理模板），鉴权用JWT。没有哪个中间件是多余的：Spring Boot负责快速的业务开发，MyBatis Plus帮你减少大量单表CRUD的重复代码，Redis用来做登录会话、验证码和热点课程的缓存，MySQL存储核心业务数据。
为什么不建议上微服务？一个毕业设计，非要把用户服务、课程服务、订单服务拆成三个工程，部署的时候你就是给自己挖坑——三个进程要启动，数据库要拆，演示时还容易因为某个服务没起来导致冷场。微服务不是不能用，但如果只是把大系统拆成小系统、没有任何分布式事务或消息中间件支撑，答辩时反而会被问住。把单体做到结构清晰、扩展点明确，就足够拿高分了。
2.2 单体架构还是前后端分离：毕设项目怎么选
在线教育系统有两种常见工程组织方式：一种是传统的单体模式，前端页面放在后端工程的静态资源目录里；另一种是前后端分离，后端只提供API，前端是一个独立的Vue工程。我建议你用第二种，原因很实际：答辩时直接把前端页面甩出来，比在浏览器里输入localhost看一个服务端渲染页面更有说服力，而且论文里的“系统实现”部分也能贴出API接口设计。
工程结构上推荐这样组织：一个后端仓库（edu-backend），一个前端仓库（edu-frontend），另外单独建一个docs目录，放数据库初始化脚本和项目文档。演示的时候先启动数据库，再启动后端，再启动前端，依次在记录台上展示清楚，这就是一个很规范的“部署流程”。
2.3 数据库表设计：先把这些核心表规划好
在线教育系统的数据库设计，很少有学生能一次到位。我给你列一个最小可用但非常完整的表清单，你照着这个设计就不会漏：
| 表名 | 用途 | 关键字段 |
|---|---|---|
| sys_user | 用户表 | id、username、password、role、avatar、status |
| edu_category | 课程分类表 | id、name、parent_id、sort |
| edu_course | 课程表 | id、category_id、title、cover、price、original_price、status、view_count |
| edu_chapter | 章节表 | id、course_id、title、sort |
| edu_video | 视频表 | id、chapter_id、title、video_url、duration、play_count |
| edu_order | 订单表 | id、order_no、user_id、course_id、amount、status、pay_time |
| edu_comment | 评价表 | id、course_id、user_id、content、rating、create_time |
| edu_favorite | 收藏表 | id、user_id、course_id、create_time |
两处最关键的细节：一是“课程发布”链路需要status字段控制状态，讲师提交后是草稿，管理员审核后变成已上架；二是订单表一定要有order_no业务订单号，不能用主键id直接当订单号给用户看，这是电商业务的基本常识。表与表之间做好外键约束或逻辑外键（推荐逻辑外键），在论文里画ER图时也会非常规整。
2.4 后端工程分层与接口风格规范
后端工程我采用标准的Controller-Service-Mapper三层结构。Controller只负责接收参数和返回结果，Service写业务逻辑，Mapper负责数据库操作。这样做不是为了好看，而是为了论文里能画出清晰的分层架构图，以及答辩被问到“某段逻辑在哪一层”时你能对答如流。
接口风格建议统一遵循RESTful，并以/api为前缀。登录接口可以设计成POST /api/auth/login，课程列表分页是GET /api/course/list?page=1&size=10，创建订单是POST /api/order/create。返回给前端的JSON统一封装成：
{ "code": 200, "message": "success", "data": {} }统一返回体这个细节，看着不起眼，实际上是你代码整洁度的重要评分项。后端所有异常也在全局异常处理器里统一捕获，返回对应的errorCode，不要让前端拿到一堆没头没尾的报错堆栈。
3. 核心模块实现思路与关键代码：从登录到支付逐个击破
3.1 JWT登录验证与角色鉴权：不让任何用户随便越权
用户登录这块，很多同学还在用Session，说实话也能跑，但答辩时会显得技术思维稍微旧一点。我更推荐你用JWT做无状态登录，理由也简单：系统是前后端分离架构，API是无状态的，每次请求带上Token，后端校验Token就能确认用户身份，这就天然契合REST架构风格。
核心实现思路分三步：登录成功时，用用户的id和角色信息生成一个JWT串返给前端；前端把Token存进localStorage，之后每个请求在请求头里带上Authorization: Bearer <token>；后端写一个拦截器，专门拦截需要登录的接口，从请求头解析Token，解析成功就把用户信息放进当前上下文，解析失败直接返回401。
代码可以精简成这样，让你心里有个底：
// 登录成功后生成Token String token = Jwts.builder() .setSubject(String.valueOf(user.getId())) .claim("role", user.getRole()) .setExpiration(new Date(System.currentTimeMillis() + 24 * 60 * 60 * 1000)) .signWith(SignatureAlgorithm.HS256, SECRET_KEY) .compact();密码存储一定要用BCrypt加密，明文密码在毕设里被评委看见是很丢分的行为。角色鉴权这块，推荐在方法上使用注解控制，比如讲师发布课程的接口只允许role=2（讲师角色）访问，管理员接口只允许role=1访问，前后端也要做对应的菜单权限动态渲染。
3.2 课程与视频资源管理：上传、播放与防盗链
课程管理是系统的内容基础。讲师登录后可以创建课程，填写标题、封面、分类、价格，然后按章节上传视频。这里如果你想做得省事一点，视频存储可以先用本地上传，把文件保存到服务器的一个专门目录，然后通过后端的静态资源映射提供给前端播放。
一个实际的小坑：Spring Boot默认上传文件大小限制是1MB，你录的课程视频随便就是几十MB，不修改配置一定会上传失败。你在项目配置文件里需要加大限制：
spring: servlet: multipart: max-file-size: 500MB max-request-size: 500MB视频播放这块，毕设级别的系统不需要自己做转码服务，直接生成一个可播放的视频地址，前端用video标签就能播放。但论文里可以稍微写一下“视频资源访问控制方案”，比如不允许未登录用户通过URL直接访问视频，给视频地址加临时签名参数，或者做简单的Referer校验，这属于实现成本很低但看起来很有深度的加分项。
3.3 订单与模拟支付：支付成功才知道课程能不能解锁
订单模块是整个系统里最像“电商”的部分，也是答辩评委最爱盯的地方。核心业务逻辑是：用户提交订单 → 后端创建待支付订单，生成唯一业务流水号 → 返回订单号给前端 → 用户点击“模拟支付” → 后端改变订单状态为已支付 → 同时往购买记录表里插入一条记录 → 用户下次进入课程详情页时，后端会检查该用户是否购买了该课程，购买过就正常播放视频，未购买则提示去下单。
这里我建议你在支付回调环节做一个“异步通知”的模拟：提供一个/api/pay/callback接口，假装是第三方支付平台回调后端的入口。回调里校验签名（可以简化成校验订单号和金额是否匹配）后，才去更新订单状态。把这一步做出来，你的论文“支付模块设计”就活了，它不再是简单的CRUD，而是有调用逻辑和状态机变化。
3.4 Redis在系统里的两个关键角色：缓存与验证码
Redis不是必须上，但上了之后你的“技术亮点”立刻多一个。最合适的使用场景有两个：第一个是首页热点课程的缓存，用户每次打开首页都要查课程列表，如果每次都去数据库查，压力会很大，你可以把首页数据缓存到Redis里，五分钟过期，后台更新课程后主动清除缓存；第二个是验证码，登录注册时需要输入图形验证码，验证码内容本来就应该存Redis并设置过期时间，几行代码就能实现。
需要注意的坑是：演示的时候Redis如果不启动，登录接口就会报错。所以代码里一定要给Redis的连接配置写好超时时间，同时你需要在README里写清楚“启动前先启动Redis”，录演示视频前最好把这条也录进去，避免现场出洋相。
3.5 后台统计报表：让数据自己说话
管理后台除了用户和课程管理，一定要有一个统计页面。统计内容可以是：每日新增用户数、每日订单数、课程销量排行榜、分类课程数量占比。前端用ECharts展示折线图和柱状图，后端用SQL聚合查询返回数据。比如课程销量排行就可以这么查：
SELECT c.title, COUNT(o.id) AS order_count FROM edu_course c LEFT JOIN edu_order o ON c.id = o.course_id AND o.status = 1 GROUP BY c.id ORDER BY order_count DESC LIMIT 10;统计模块看起来很“加分”，但代码量并不大，而且它给了你一个非常自然的演示环节——打开后台看图表，比干巴巴地列表格有说服力得多。
4. 源代码工程怎么组织，演示视频怎么拍
4.1 工程目录结构：让答辩老师一眼看明白
源代码的目录结构建议这样安排：
edu-system/ ├── docs/ # 数据库脚本、项目说明、环境配置手册 ├── edu-backend/ # 后端Spring Boot工程 ├── edu-frontend/ # 前端Vue工程 └── README.md # 启动说明后端内部按业务模块分包，不要所有Controller堆在一个包下面。我的习惯是com.xxx.edu下分成controller、service、mapper、entity、config、common这几个子包，这样论文里的“工程结构说明”就可以直接用目录截图加文字讲解。数据库脚本放在docs目录下，里面既要建库又要插入演示数据，别只给个空表结构。
4.2 本地启动的全流程：从环境到页面
毕设演示最怕的就是环境问题。我建议你至少提前一周在干净的电脑/虚拟机上完整跑一遍启动流程，别等到答辩前一天才第一次用别人的电脑试。标准流程是：
- 安装并启动MySQL，执行docs下的init.sql初始化脚本
- 启动Redis服务
- 用IDEA打开edu-backend，配置application.yml里的数据库账号密码，启动Spring Boot工程
- 用VS Code或命令行进入edu-frontend，执行npm install后运行npm run dev
版本搭配我也给你一个实测下来很稳的组合：JDK 8或11 + Spring Boot 2.7.x + MySQL 8.0 + Redis 6.x + Node.js 16/18 + Vue 2或3。这个组合网上资料多，踩坑资料也多，出问题了能搜到答案。如果你用了Spring Boot 3.x，就要注意JDK版本必须是17，很多教程还停留在老版本就照着写，容易出莫名其妙的问题。
4.3 演示数据准备：让你的系统看起来有“内容”
很多学生的系统里只有一两条测试数据，演示的时候空荡荡的，截图也不好看。我强烈建议你有意地造一批数据：比如5个课程分类，每个分类下四五个课程，每门课两三个章节，每个章节一两个视频（可以用测试小视频文件代替），再加十几条订单和评论。这样首页、详情页、讲师后台、管理后台每个页面都有足够的内容展示。
演示账号也建议提前准备好：一个学生账号、一个讲师账号、一个管理员账号。密码务必统一，答辩输入密码时不要手抖。最好把密码直接写在PPT最后一页的“环境说明”里，省得现场记错。
4.4 演示视频怎么录：8到15分钟抓住重点
演示视频现在很多学校都要求作为提交材料，有些是因为线上答辩，有些是做存档。视频的核心原则是“宁短勿长，流程关键点必须完整”。建议脚本如下：开头花30秒展示项目背景和功能结构，然后按“学生端流程 — 讲师端流程 — 管理端流程”三段进行，每段挑选两三个关键场景操作，最后用30秒展示代码结构和核心代码片段。
录制工具用OBS或Screen Recorder，用固定分辨率录制，别录到一半窗口乱跳。边录边开一个标记脚本，把要讲的几段话写在旁边，避免现场语无伦次。视频文件命名可以规范一点，比如学号-姓名-在线教育系统演示.mp4，这类细节都会给老师留下好印象。
5. 毕业论文到底怎么写：从目录到查重一次说清
5.1 论文框架：一套能直接用的目录结构
在线教育系统的论文结构高度成熟，你不需要任何标新立异的目录，按以下顺序来最稳妥：摘要（中文）、Abstract、目录、第一章绪论、第二章相关技术介绍、第三章系统需求分析、第四章系统设计、第五章系统实现、第六章系统测试、第七章总结与展望、参考文献、致谢。
每一章篇幅分配大概是：绪论和文献综述合计4页左右，相关技术2-3页，需求分析5-8页，系统设计8-10页，系统实现15-20页，测试3-5页，总结1-2页。论文总字数一般要求1.2万字以上，按这个分配写不会缺字数，关键是每一章都要有图和表来支撑，不能全是纯文字。
5.2 各章节写作要点：避免“记流水账”
绪论章节常见问题是写成了“百度百科式”的背景介绍。正确的写法是：先说明在线教育的市场实际背景，再引出本系统的开发目标，最后简单交代论文的组织结构。相关技术介绍选主流的4到5个技术写就行，比如Spring Boot、MyBatis Plus、MySQL、Redis、Vue，每个技术的介绍控制在半页到一页，不要写成长篇文档。
需求分析章节要放用例图，画出学生、讲师、管理员的用例；功能需求按照模块用表格描述；非功能需求要写安全性、性能、可维护性。系统设计章节重点放架构图（前后端分离架构图）、功能模块图、数据库ER图、核心表结构。到了系统实现章节，每个功能模块都要有“页面截图+核心代码+说明文字”，截图要清晰的彩色图，代码不要截长图，用两三个关键方法即可。
5.3 系统测试章节：不是简单列几条就完事
测试章节是最容易被忽视、又最好写的部分。至少包含三类测试：功能测试、性能测试、兼容性测试。功能测试用表格列出用例编号、测试步骤、预期结果、实际结果，覆盖登录、课程管理、下单支付、评论等核心场景。性能测试可以用JMeter对登录接口和课程列表接口做一个简单压力测试，给出并发100时的响应时间截图和结果分析，这几乎是现成的加分项。兼容性测试就是写在不同浏览器下的表现。
5.4 论文排版与查重心得：先查一遍再定稿
排版必须严格按学校模板来，图表要有编号，公式要用编辑器，目录自动生成。查重这块，我见过太多学生辛辛苦苦写出来的初稿，因为大量粘贴了博客或技术文档的代码注释被标红。自己写的代码阐述部分用词尽量口语化，所有引用到的概念要重新用自己的话组织。大段代码不要直接扔进论文，核心方法贴五到十行并配上自己的解释，这是控制查重率最有效的办法。
6. 答辩PPT怎么设计：页面规划与回答思路
6.1 PPT页面规划：用15页以内讲完全部亮点
答辩PPT不需要长，关键是结构完整、逻辑清楚。我建议控制在12到15页之间，页面安排：
| 页码 | 页面标题 | 核心内容 |
|---|---|---|
| 1 | 封面 | 题目、姓名、学号、导师 |
| 2 | 项目背景与意义 | 在线教育需求背景、选题价值 |
| 3 | 核心功能概述 | 三种角色、功能列表、功能图 |
| 4 | 技术架构 | 前后端架构图、技术栈列表 |
| 5 | 数据库设计 | ER图、核心表汇总 |
| 6 | 学生端演示引导 | 学生端核心页面截图 |
| 7 | 讲师端演示引导 | 讲师端核心页面截图 |
| 8 | 管理端演示引导 | 管理端核心页面截图 |
| 9 | 核心模块详解1 | 登录鉴权模块流程图与核心代码 |
| 10 | 核心模块详解2 | 订单支付模块流程图与核心代码 |
| 11 | 核心模块详解3 | 视频管理与缓存设计 |
| 12 | 测试结果 | 测试用例表、性能测试截图 |
| 13 | 总结与展望 | 项目收获、可扩展方向 |
| 14 | 谢谢/问答页 | 请各位评委老师指正 |
6.2 每页怎么讲：控制节奏，避免照着念
每页PPT的讲解时间建议控制在40到50秒，整场答辩演示加讲解控制在8到12分钟，不要超时。讲项目背景时别花太多时间，重点是技术架构和业务闭环。演示部分开场先拿学生账号完整走一遍“浏览-下单-支付-学习”的链路，这是最有说服力的一轮。然后切讲师账号，演示课程发布与视频上传，最后切管理员账号，演示审核和统计。
每个页面上字越少越好，只保留关键词、核心数据、架构图，其余靠嘴讲。不要为了显得内容多把PPT塞满文字，评委看密密麻麻的PPT会直接走神。过渡话术自然一点，比如“数据库设计完了以后，我来讲一下核心模块的实现逻辑”，比“下面介绍第三章系统设计”听起来专业得多。
6.3 答辩高频问题与应对策略
准备答辩，光准备讲稿不够，你要把评委可能问的问题提前列出来回答一遍。我总结了在线教育系统最容易被问到的几类问题：
- 为什么选择这个技术栈，不用别的？
- JWT和Session的区别，你的方案有什么优缺点？
- 订单支付模块怎么保证同一个课程不会被重复购买？
- 如果讲师上传了一门课程，这个过程的状态是怎么流转的？
- 如果用户量很大，你的系统会怎么优化？（这个就是送分题，答Redis缓存加数据库索引，再加Nginx负载均衡即可）
回答问题时不要背书式地长篇大论，按“怎么设计的—为什么这么设计—如果遇到极端情况怎么优化”三层来回答，评委听着条理就清楚。遇到不会的问题就承认“这块我还没有深入研究，但我的理解是”，态度诚恳比硬编答案要好得多。
7. 踩坑清单：我在指导这类项目时见过最多的坑
7.1 环境配置类问题：这类坑占了六成
第一大类是环境和启动问题。比如Spring Boot版本和JDK版本不匹配，新版本要求JDK 17，旧教程还让你用JDK 8，编译直接报错。还有MySQL 8.0的时区问题，连不上数据库一般就是驱动或时区配置的问题，连接串里加上serverTimezone=Asia/Shanghai基本能解决。Redis没启动导致登录失败这个问题也是高频中的高频，尤其是录视频那天一紧张就忘。
解决办法很简单：写一份环境启动手册，把每个中间件的启动命令、检测办法都写清楚，一个环境一个环境地打勾确认。不要等到答辩现场，一边拼凑一边试错。
7.2 代码与业务逻辑层面的坑：越权、重复提交、资源路径
第二大类坑在业务逻辑。最典型的：学生购买课程后，直接通过前端修改路由去播放视频，或者通过接口直接请求视频URL，就能绕过支付。这个问题的本质是后端没有做“当前用户是否已购买该课程”的校验。在编写视频播放接口和课程详情接口时，一定要拿到当前登录用户的信息，再去查询购买记录表，而非只看前端传了课程ID就返回数据。
重复下单也是常见问题。用户快速点击提交订单按钮，可能在后端创建了多个订单。解决思路有两种：一是前端提交后按钮置灰；二是后端用一个幂等机制——在创建订单前，查一下该用户对该课程是否存在“待支付”状态的订单，如果存在就直接返回现有订单号。
7.3 论文与答辩层面的坑：图片模糊、代码成段贴、时间超时
第三大类坑发生在论文和答辩环节。截图模糊、有黑边、标注不清楚，都是很常见的扣分点。截图之前调整好浏览器窗口大小，放大到100%以上再截。代码不要成段贴，每段代码十行以内，配上说明。还有一句提醒，论文中出现的所有用户名、邮箱、手机号都尽量用拟造的测试数据，不要出现真实个人手机号。
答辩演示时时间超时是最亏的，明明准备了丰富的测试结果，结果讲前面太久，最后后台模块都没来得及打开。建议答辩前自己彩排两轮，掐表算一下每个模块的演示时间，给学生端主讲留最多的时间，后台模块点到即止。
我个人带过不少学生做这类毕设，最大的感受是：真正拿高分的同学，并不是代码写得多高级，而是把“从需求分析到技术选型到实现到测试”这条逻辑链完整讲清楚了。一个结构清晰、能自圆其说的在线教育系统，比一个堆了不少技术但逻辑混乱的项目，在老师眼里要高不知道多少个档次。所以拿到这个题目别慌，按顺序把需求理清、模块拆开、论文按部就班写，答辩时把你做过的每一个决策背后的为什么说明白，这个毕设就稳了。