企业官网建设流程全解析

1. 这个项目到底在解决什么：从传统学习平台到融媒体交互的转变

每年到了毕设选题季，总有一批同学拿着“基于 Spring 的融媒体交互学习平台”这类题目来问我，第一句话往往都是“老师，这个题是不是换了个包装的网上课堂”。说实话，第一次看到这个题目的时候我也觉得它平平无奇，但真正把需求理清楚之后才发现，这个题其实把本科阶段最常见的几个技术点全串起来了：权限管理、多媒体存储、内容发布、交互反馈、数据统计，任何一个环节都能挖出足够多的设计细节来支撑一篇合格的毕业设计论文。

为什么说它不只是一个“网上课堂”？传统的学习管理系统通常只有两类页面：管理员上传课件，学生下载课件或者看一个网页版的文档。这种形态最大的问题在于“内容”和“交互”是割裂的。课件放在一个模块里，论坛放在另一个模块里，学习进度完全靠老师口头询问。而融媒体交互学习平台的核心命题，是把富文本图文、在线视频、音频素材、随堂测验、实时问答、学习进度追踪这些能力统一到一套系统中，让学习者在一个页面里就能完成“看内容—做练习—提问题—看反馈”的完整闭环。

举个具体的例子。某高校内部在用的一个网课平台，学生看完一个视频之后，如果想提问，必须退出视频页面，去另一个讨论区发帖，发完帖再回到课程内容继续看下一节。这个操作路径虽然也能完成，但跳转次数一多，学生的流失率是肉眼可见的。而我们设计的融媒体交互学习平台，会把视频播放器、底部随堂提问框、右侧笔记面板放在同一屏内，学生遇到听不懂的地方直接在旁边打字提问，学习记录会自动带上当前视频的播放时间点，老师回答时能精确知道“这个学生是在视频第几分钟产生的疑问”。这种体验上的差异，就是“交互式学习”和“传统点播”之间最本质的区别。

从毕设的角度看，这类项目的受众其实很明确：准备选这个课题的计算机专业学生，需要一套从需求分析到系统实现再到论文写作都说得通的技术路线；以及想快速搭建一个轻量级学习管理系统的开发者，这些人不一定需要完整的商业化解决方案，但要有一份能用、能扩展、能讲清楚的代码骨架。如果你属于这两类人，这篇文章应该能帮你省下大量在搜索引擎里来回跳转的时间。

2. 整体架构与模块拆分：先把系统切分成能落地的功能边界

2.1 选题名称里的“Spring”和代码落地时的“SpringBoot”是什么关系

很多同学拿到课题名称的时候会困惑，题目写的是“基于 Spring 的融媒体交互学习平台”，可网上的教程全是 SpringBoot，这俩到底是不是一回事。这里要说清楚：课题名称里的“Spring”是一个宽泛的技术族概念，而实际开发时我们默认都是基于 SpringBoot 来做。原因很简单——SpringBoot 本质上就是 Spring 框架的自动化配置封装，它把 Spring MVC、Spring JDBC、事务管理这些底层组件整合成了开箱即用的工程结构，省掉了大量 XML 配置。在毕设答辩时，如果老师追问“你的项目里 Spring 体现在哪里”，标准回答是“SpringBoot 是 Spring 生态的一种快速开发方式，核心依赖仍然是 Spring 的 IoC 容器、Spring MVC 的请求处理链路和 Spring JDBC 的事务控制”。

所以这篇文章的技术路线明确为：后端 SpringBoot 2.7 + MyBatis-Plus，前端 Vue 3 + Element Plus，数据库 MySQL 8.0，缓存 Redis，认证方案 JWT。这个组合并不极端，也不是为了秀技术，选它是因为它正好覆盖了“用户管理—内容管理—交互功能—数据展示”这条主链路，而且每个点都能对应到课程里学过的知识点，论文里好写、答辩时好讲。

2.2 功能边界的划分：四类角色和三块业务域

系统功能的划分不能上来就写“有登录、有注册、有增删改查”，那会让后面的设计和编码全乱套。我习惯的做法是先把使用者列全，再根据角色的操作边界去反推功能模块。这套平台的用户一共分为四类：

基于这四类角色，业务域分成三块：内容域负责课程、章节、媒体素材的管理与展示；交互域负责问答、笔记、测验、评论这些用户产生的内容；数据域负责学习进度、行为记录、统计报表的沉淀。三块业务域的边界必须在建表之前就明确，否则容易把字段到处乱塞——比如把“视频播放进度”塞到章节表里，这种设计短期能跑，一旦支持多端（手机端看完续播到电脑端）就会出大问题。

2.3 前后端分离与工程结构设计

工程结构采用前后端分离，后端按模块分包，前端按页面组织。后端的包结构我建议这样安排：

com.campus.mediaplatform ├── common // 统一返回结果、全局异常、通用工具类 ├── config // 配置类（拦截器、静态资源映射、跨域） ├── controller // 接口层，只做参数接收与结果返回 ├── service // 业务层，事务边界在这里控制 ├── mapper // MyBatis-Plus 的 Mapper 接口 ├── entity // 数据库实体类 ├── dto // 请求与响应对象 └── utils // JWT工具、文件上传工具等

controller 层不做任何业务计算，service 层不出现 HttpServletRequest 这类 Web 层对象。这个规约在项目初期就要定死，否则代码写到一半，每个人写的风格不一样，后期合并时非常痛苦。有一次我带学生做项目，到了联调阶段发现某个接口在 controller 里直接调了 Redis 操作，另一个接口又在 service 里返回了 JSON 字符串，导致前端对接时数据类型时好时坏，最后花了一整天统一规范。

前端部分按页面拆分为：登录注册页、课程列表页、课程详情页（含视频播放、文档预览、测验、问答Tab）、个人中心页（学习进度、收藏、笔记）、教师工作台（内容管理、学生列表）、管理后台。Element Plus 负责表格、表单、弹窗这些基础组件，视频播放器可以考虑使用原生组件配个自定义控制条，或者接入第三方播放器做断点续播。

3. 数据库模型设计：支撑内容与学习记录的核心表长什么样

3.1 内容模型：不把“媒体类型”写死成字段

数据库设计是这类项目地基中的地基。先看内容域。很多同学第一反应是建一张课程表、一张章节表、一张视频表，这么做的问题是：一个章节里可能既有视频又有图文还有音频，如果你建的是 video 表，那图文怎么存？再建一个 article 表？那音频是不是还要建一个 audio 表？表越建越多，业务层的判断逻辑越来越散。

我的做法是：章节表只保存结构化元数据，具体的媒体素材统一放到一张素材表里，用资源类型字段区分是视频、音频还是图片。章节与素材是一对多的关系，素材表里包含素材URL、素材类型、排序权重、上传时间等字段。查询某个章节的全部素材时，按权重排序返回，播放器侧根据类型渲染对应的组件。这个设计的好处是以后要增加新的素材类型（比如3D模型预览、互动H5），不需要改表结构，只需要在枚举类型里加一个值。

章节表的字段包括：章节ID、所属课程ID、章节标题、排序号、简介、是否免费试看、创建时间。课程表则要额外冗余一个封面图URL和一个简介字段，因为课程列表页每次加载都要展示封面和一句话简介，不冗余的话每次都要多查一次素材表，没必要。

3.2 交互模型：问答、笔记、测验共用一套“内容生产”逻辑

交互域里最容易踩的坑是把每个功能都当成独立的表来设计。问答一条表、笔记一条表、评论一条表，然后每个表单独做一套分页查询接口。虽然业务上也能跑通，但代码重复率非常高。更好的方式是抽象出一张通用的“用户内容表”，用内容类型字段区分是提问、笔记、评论还是测验提交，再配一张关联表说明这条内容挂在哪个章节下。

当然，这个抽象对于毕设而言可能显得有些过度设计。折中方案是：问答表和笔记表单独建，但保留相似的字段结构（用户ID、章节ID、内容、创建时间、状态），代码层面用 MyBatis-Plus 查出数据后，在 service 里统一组装用户头像和昵称。测验表单独建一张，因为它的结构更特殊——除了题干和选项，还要存正确答案和答案解析，这跟文本类的问答完全不同，硬塞进通用表只会让字段大量留空。

3.3 学习进度模型：记录“看到哪”比记录“看了没”更有价值

学习进度是交互学习平台的核心竞争力。一张合格的学习纪录表至少要能回答三个问题：学生学的是哪个章节的哪个素材？学到了什么位置（视频的秒数、文章的滚动高度、测验的完成状态）？这个记录是什么时候更新的？

视频学习进度的表设计大概是：

• 记录ID、学生ID、章节ID、素材ID
• 最后播放位置（秒）
• 视频总时长
• 学习状态（未开始/学习中学完）
• 最近学习时间

每条记录建议用“学生ID+素材ID”建唯一索引，每次上报播放进度时做 upsert 操作，有就更新、没有就插入。测验记录表则要单独保留每次提交的答题明细（试题ID、所选选项、是否正确），这样不仅能统计得分，还能分析某个学生对某个知识点的掌握情况，这部分数据后面的统计图表会用到。

3.4 用户与权限模型：RBAC 简单但不能省

权限模型采用经典的 RBAC（基于角色的访问控制），五张表：用户表、角色表、菜单权限表、用户角色关联表、角色菜单关联表。毕设项目通常涉及不到复杂的部门层级，五张表完全够用。用户表里要预留一个状态字段用于启用禁用，密码用 BCrypt 加密存储，不要在数据库里存明文字段。

这里给一个设计提醒：不要把“教师”和“管理员”直接合并成一个角色。虽然教师和管理员都能发布内容，但管理员还要管用户和系统配置，如果合并了，后续想区分权限就要加一堆 if 判断，不如一开始就按角色拆开。

4. SpringBoot后端实现：权限、内容、交互、学习进度四个关键模块

4.1 统一返回结构与全局异常处理：先定规则再写代码

后端代码的第一行，我建议先写统一返回结构而不是先建表。定义一个通用的 Result 类，包含状态码、消息、数据三个字段，所有接口统一返回这个结构。这样前端处理接口时会非常统一，错误判断只需看状态码。配合 @RestControllerAdvice 全局异常处理器，把所有业务异常和系统异常统一转换成 Result 结构返回，前端不用为每个接口单独写 try-catch。

这个设计的好处要到联调阶段才能体会到。如果没有统一返回结构，每个人写的接口返回格式都不同，今天这个返回{code:1,data:[]}，明天那个返回{success:true,result:[]}，前端对接一个接口就要看一次后端代码。这种混乱会让整个项目后期变得极为痛苦，务必在一开始就掐掉。

4.2 基于JWT的登录与拦截器权限校验

登录认证用的是 JWT，流程是：用户提交账号密码，后端验证通过后用用户ID和角色信息生成 token，前端把 token 存在本地存储中，每次请求在请求头带上Authorization: Bearer <token>。后端定义一个拦截器，在 preHandle 方法里校验 token 是否有效，解析出用户信息后存入 ThreadLocal 上下文，Controller 方法里直接取出使用。

权限校验使用拦截器和注解配合的方式。先定义一个@RequireRole注解，标注在 Controller 方法上表示该方法需要什么角色才能访问。然后在拦截器里检测到方法上有这个注解时，从 token 解析出的角色信息进行比对，不一致直接返回 403。这种方式比每个方法里手写判断简单得多，而且出错的概率低。

这里有一个容易忽略的细节：拦截器放行规则必须配清楚。登录接口、注册接口、首页课程列表接口是要放行的，其余接口原则上都要校验。不要把放行规则和拦截规则混为一谈，严格来说应该是“默认拦截，显式放行”，而不是“默认放行，显式拦截”。后者一旦忘记加拦截配置，接口就裸奔了。我在逐个检查接口时曾发现一个安全隐患：某个学生把"/**"放在了排除列表里，整个项目的权限拦截全部失效，浏览器直接访问接口就能拿数据，这种问题如果在答辩演示时被老师发现，答得再好也会打大折扣。

4.3 媒体文件上传与静态资源映射

融媒体平台的核心内容是媒体文件，所以上传功能必须优先做好。两个关键配置：

第一，上传文件的大小限制。SpringBoot 默认限制单文件大小为 1MB，这个值是没法满足视频上传需求的。需要在配置文件中调大spring.servlet.multipart.max-file-size和spring.servlet.multipart.max-request-size，视频文件通常要开到达 2GB 左右。同时要做好前端分片上传的准备，如果文件过大直接走整包上传，很容易因为请求超时或网络波动导致失败。毕设阶段我建议上传模块实现到“本地磁盘存储+URL映射”级别就够：文件保存到服务器指定目录，通过 WebMvcConfigurer 将目录映射成/upload/**的URL路径，用户访问时直接拼接地址。

第二，静态资源跨域。如果前端和后端不是同一个域名部署，需要在后端配置跨域规则，允许前端域名访问上传的静态文件。跨域问题在本地开发时通常通过前端代理解决，但部署到服务器后如果前端用 Nginx 转发，后端又单独开了端口，跨域配置就必须显式写清楚，不然图片视频全挂。

4.4 学习记录上报接口与断点续播的时序设计

“断点续播”是学习进度模块里最容易被问细节的点。前端视频播放器在播放过程中定时（通常3-5秒）向后端上报当前播放位置，后端拿到位置后更新学习记录表。这里有两个设计决策：

上报频率。建议用节流方式控制，不要每次播放时间变化都发请求，否则视频播放一分钟要发20个请求，对数据库压力不小。前端每次上报时把视频完整状态带上，后端全量更新。

视频结束的判定。不能只凭播放器触发 ended 事件就认定学完，因为用户可能拖动进度条到结尾让视频秒结束。更可靠的方式是根据记录表里的最大播放位置来判定：当最大播放位置超过视频总时长的95%，就标记为学完。前端展示进度进度条时，读取最近一条学习记录，计算百分比。

4.5 点赞、收藏、访问量的缓存设计

交互功能里有一个用 Redis 非常经典的位置——热点数据计数。课程的访问量、点赞数、收藏数，这些数值的特点是读多写少，而且要求实时可见。每次点击都去数据库里刷一遍 count 字段，数据库压力大不说，事务也会变得复杂。我的做法是：

用 Redis 的 Hash 结构存储课程的计数信息，key 是课程ID，field 是“view”或“like”，每次访问或点赞时执行HINCRBY操作。课程详情页展示数据时先去 Redis 查，查不到再回源数据库。后台提供一个定时任务，每隔一段时间把 Redis 里的计数同步回 MySQL 的课程表。这个方案虽然多了个中间组件，但计数这块的响应速度确实比直接查库快了一个量级。用户在点赞后能看到数字立刻加一，这个体验对交互平台来说很重要。

点赞防重复用 Redis 的 Set 结构解决：SADD {课程ID}:likedUsers {用户ID}，如果返回1说明是第一次点，加计数；如果返回0说明重复点击，接口直接提示“请勿重复点赞”。

5. 前端联调与融媒体展示的细节处理

5.1 页面结构与学生端学习路径

前端的核心页面是“课程详情页”，它承载了融媒体内容的主要展示形态。设计时把页面拆成左中右三栏：左侧是课程的章节目录，可以折叠展开；中间是主要内容区，根据素材类型动态切换视频播放器、图文预览或音频播放器；右侧是问答与笔记面板，支持切换Tab。三栏联动是关键：点击左侧章节时中间内容切换，同时右侧问答列表刷新为该章节下的提问内容。

代码组织上，Vue 组件可以拆成CoursePlayer.vue（播放器封装）、ChapterList.vue（章节目录）、QaPanel.vue（问答面板）、NotePanel.vue（笔记面板），各自通过 Props 接收数据、通过事件向上传递交互动作。用 Pinia 管理当前用户信息与学习进度状态。这套结构虽然比单文件组件复杂一些，但后期维护时想改某个面板的样式或逻辑，完全不会影响其他模块。

5.2 富文本与视频播放的选型心得

图文类媒体内容需要一个富文本编辑器。比较常用的有三个方向：原生 textarea 配合 Markdown，或者集成 wangEditor，再来就是更多功能的 Quill。毕设项目里我建议 wangEditor 就够了，它对中文场景支持好，上传图片的功能也有，学习成本低。要注意的是富文本内容在后端要通过 XSS 过滤，不然用户往编辑器里贴一段包含 script 标签的内容，前端渲染时会执行恶意脚本这个坑后面章节详细说。

视频播放器我建议用成熟的播放器库，重点不是播放本身，而是与进度记录的联动。监听播放器的 timeupdate 事件，节流上报学习记录；监听 ended 事件，标记课程学完。如果项目需要对接自己的视频业务做防盗链校验，就需要在播放器层面加自定义请求头，这属于扩展范畴，毕设不做硬性要求。

5.3 接口联调的时候最容易出问题的地方

前后端联调最常见的坑是“字段名对不上”和“时间格式不一致”。后端返回的 JSON 字段命名习惯不同，有的用驼峰、有的用下划线，虽然前端可以手动映射，但联调效率会严重下降。建议后端在配置里开启 MyBatis-Plus 的驼峰转下划线自动映射，前端这边统一用后端定义好的字段名，不要自己改名字。

时间格式不一致也很头疼。MySQL 的 datetime 类型返回到前端时可能是2025-01-15T12:30:00这种格式，也可能是时间戳，前端想要展示成2025-01-15 12:30就得自己写格式化函数。建议后端在全局配置中统一 JSON 序列化的时间格式，避免每个时间字段单独处理。

6. 开发中踩过的坑：一次日志引发的排查复盘

6.1 富文本内容保存后“神秘消失”背后是 XSS 过滤在拦截

某一个版本的开发中，某学生反馈说发布课程介绍时，只要内容里包含图片或者加粗文字，保存后再编辑就变成空白了。第一反应是内容没保存成功，但查看数据库发现里面有数据。反复测试后发现，编辑器生成的 HTML 一旦包含自定义样式属性，后端存入数据库和读取时就会被过滤规则删掉，导致页面渲染内容为空。

排查过程是这样的：先在后端接口打印请求体，确认前端传上来的 HTML 片段完整；然后在 service 层打印保存前的变量，内容也完整；问题锁定在数据到达数据库之前的某个环节。查阅项目依赖发现，引入的 XSS 过滤框架默认启用了白名单策略，白名单之外的所有标签和属性一律被清除。图片标签的 class 属性、字体标签的 style 属性全被过滤掉了。

解决办法是把过滤框架的策略调整成保留常用排版标签和属性，同时只过滤 script、iframe、事件触发性属性（onclick 等）。这个坑提醒了所有人：安全组件和安全策略默认是偏保守的，加进项目之后一定要做一轮页面级回归测试，尤其是富文本这种意图就是要“允许用户写 HTML”的场景，安全策略和业务需求之间必须做一次仔细的权衡。

6.2 跨天的学习时长统计发生错乱：数据库时区与 Java 时区不一致

学习统计模块完成后，某导师反馈说某个学生“昨晚11点到今晨1点”的学习时长记录全部丢失。查看数据后发现，这条跨天记录的学习日期归属到了前一天，导致第二天的统计少了两小时。排查中发现 MySQL 连接串里没有指定 serverTimezone，数据库连接的时区与 Java 应用默认时区不一致，日期字段在存取时发生了偏移。

解决方式统一在 MySQL 连接字符串中显式指定serverTimezone=Asia/Shanghai，并在 Java 配置里统一使用东八区时区。这个问题不只在统计功能里出现，用户注册时间、内容发布时间、最后登录时间，凡是没有显式声明时区的系统都可能踩到。第一次排查这类问题时往往不会往时区方向想，但凡是涉及“日期归属到哪一天”的逻辑，时区问题都是必查项。

6.3 视频上传明明配了 2GB 限制，为什么传 500MB 就报错

调大文件上传大小限制后，测试环境传小视频正常，传到大概 500MB 左右仍然报错。查看后端日志发现报的是连接重置，但 Nginx 访问日志显示请求根本没有到达后端。这台测试服务器前面挂着 Nginx 做反向代理，默认的client_max_body_size是 1MB，所有超过 1MB 的请求在 Nginx 这一层就被拦了。

这个坑在两个环节之间来回排查花了一些时间，但定位到之后其实一句话就能说清楚：文件上传涉及几层限制，前端请求、Nginx 反向代理、后端 Servlet 容器缺一不可。只调后端的 max-file-size 是不够的。排查时最好的办法是逐层确认：先看请求是否到达 Nginx，再看是否转发到后端，最后看后端是否正常处理。以后凡是出现“改了配置却还报错”的情况，先按这个链路一层层剥开，别盲目猜。

6.4 拦截器放行规则误配：一次差点裸奔的接口

这个在前面提过，但值得单独复盘。排查接口权限时，某学生一直抱怨说“我写的接口明明要登录才能访问，但还是被拦截器放行了”。我去看了拦截器的配置类，发现他把要放行的接口列表写成了"/**"，这意味着所有请求都无需校验直接进入 Controller。这个表达式本意是“登录和注册页面放行”，却让整个系统的权限体系形同虚设。

为什么发出这种问题？通常是因为网上搜索了片段配置代码，随手复制粘贴没有逐行阅读。修复方式很简单，把"/**"从放行列表中移除，明确写出/api/auth/login、/api/auth/register这些具体路径。这次事故之后我定了一个规矩：拦截器配置写完后，用两个接口验证——一个公开接口、一个需鉴权接口，各访问一次看是否按预期放行与拦截。这比盯着配置文件反复看不直观得多，但效果立竿见影。

7. 打包部署与答辩准备的实用清单

7.1 后端打成 jar 包还是 war 包

SpringBoot 项目默认可以打成可执行的 jar 包，内嵌了 Web 容器，放在服务器上直接java -jar就能跑。毕设项目我建议用 jar 包方式，因为部署简单、依赖集中。有些学校要求“部署到 Tomcat 中演示”，这时就打 war 包放到外部 Tomcat 的 webapps 目录下。两种方式的切换在 pom.xml 里调整 packaging 即可，但要注意打 war 包时 SpringBoot 的启动类需要继承一个初始化器类，这一步比较容易遗漏。

配置文件分离也要提前做。开发环境的数据库地址、Redis 地址跟生产环境可能不同，如果每次部署都要改代码里的配置，不仅麻烦还容易出错。使用application.yml作为公共配置，application-dev.yml和application-prod.yml分别保存不同环境的差异配置，启动时用--spring.profiles.active=prod指定。数据库密码等敏感信息不要写在配置里提交到代码仓库，部署时通过环境变量或外部配置文件覆盖。

7.2 一套合理的最小部署方案

毕设演示用的服务器配置不需要高端，一台内存4GB以上的云服务器就足够。部署组件包括：MySQL 8.0、Redis、后端 jar 包、前端打包后的静态文件。

前端项目构建后会在dist目录下生成纯静态文件（HTML、JS、CSS）。有两种部署方式：简单做法是直接让 SpringBoot 托管静态资源，把dist目录里的文件复制到后端的static目录下，这样前端页面和后端接口同端口访问，没有跨域问题；更标准的生产做法是用 Nginx 托管前端文件，再按路径将/api开头的请求反向代理到后端服务端口。我建议毕设答辩演示时用第二种方式，因为 Nginx 配置本身也可以作为一个加分项讲讲。

7.3 答辩时老师最爱问的几个技术问题

结合多年带毕设的经验，融媒体学习平台这类题目的答辩现场，老师提问一般聚焦在四个方向：

第一个方向是“你的系统比别人强在哪”。不要回答“用了 SpringBoot 所以强”，要聚焦在“融媒体内容统一管理、学习进度断点续播、问答与学习行为联动”这些业务创新点上。

第二个方向是“权限是怎么控制的”。关键要讲清拦截器加注解的方式，以及 token 的校验流程，如果能顺带提一嘴 Shiro 或 Sa-Token 这类框架的对比，会显得思考更深入。

第三个方向是“视频上传和播放的流程”。要能把请求从浏览器到服务器再到视频播放的完整路径讲述清楚，包括上传限制、静态资源映射、播放器加载过程。

第四个方向是“数据库为什么这么设计”。重点解释素材表和课程表的关系、学习记录表为什么用 upsert、计数器为什么用 Redis 而不是直接更新数据库。

7.4 论文撰写的素材组织建议

代码写完后再动笔写论文，是效率最高的顺序。论文的核心章节应该与系统模块一一对应：需求分析章节对应角色划分和用例图，系统设计章节对应架构图和数据库设计，系统实现章节对应核心模块的代码思路和功能截图，测试章节对应功能测试用例和关键性能数据。开头提到的“设计”和“实现”两个词，对应的正是论文中的“系统设计”和“系统实现”两大核心章节。

论文中不要贴大段代码，而是把关键算法或核心流程用伪代码或流程图表达。比如学习进度更新策略，用文字加伪代码描述“当播放位置超过视频总时长95%时自动标记为学完”，比贴一整段前端 JS 代码更让导师喜欢。测试章节要有真实数据支撑，至少测出“并发10个用户同时访问课程详情页时接口响应时间平均值”“视频上传2GB文件耗时范围”这类定量结果，哪怕数据不漂亮也没关系，真实最重要。

答辩演示建议准备一份数据脚本，提前在系统中填入多个用户、课程、视频和测验数据，演示时直接登录即可看到完整效果，避免现场边操作边造数据导致的冷场。

最后分享一个个人经验：做完这个项目之后，其实还可以沿着“推荐学习路径”的方向做二次扩展——根据学生的学习记录自动推送合适的课程或习题，这背后是协同过滤或标签匹配的逻辑。毕设阶段把基础功能做扎实，答辩时把这个“以后可以怎么发展”的想法作为收尾抛出去，老师通常都会觉得你有完整的技术视野，这比被动等提问的效果要好得多。