最近帮某高校的几个学生看毕设发现一个特别典型的选题方向题目又长又绕一口气挂了三个系统名——“智享圈”新媒体学习网站、“智汇云”新媒体知识共享平台、“媒学坊”数字内容创作教学系统。乍一看以为是三个项目其实是一条需求拆出来的一个系统只是站方给了三种叫法说白了一个网上学习平台既要能看文章视频、又要能开课教学、还得让用户之间产生互动和知识沉淀。这种题目在Java毕设里属于“看着简单、做着发懵”的类型功能似乎都是常规CRUD但真把需求落到表结构、接口和前端页面上很多人会卡在“不知道先做什么、后做什么”以及“做出来像一堆零散页面不像一个完整产品”。这篇就按我实际跟学生调试时用的思路把这类题目从拆题、选型、数据库设计到核心实现和答辩准备完整过一遍给还没开工或者已经写了一半代码的同学做个参考。1. 三个名字不是随便起的先把业务角色和模块边界理清楚毕设第一步不是写代码而是把题目里的每个词翻译成功能需求。这三个名字如果拆开看其实对应了三个模块群它们之间有交集但关注点不同。1.1 “智享圈”社区与互动“圈”字暗示的是人际关系和内容流动。一个新媒体学习网站如果只有内容没有评论、点赞、收藏、关注那就只是个单向展示的“橱窗”撑不起“学习圈”这个概念。所以第一个模块群一定包含用户注册登录、个人主页、关注/粉丝、内容浏览、点赞、收藏、评论回复、私信或站内通知。这些功能对毕设来说不是难点但要注意它们之间的关联评论要有评论者和内容ID点赞要处理“点过再点取消”的状态收藏要有分类标签关注要影响信息流。如果只把表建出来不做关联界面会很散。1.2 “智汇云”知识共享与聚合“云”和“汇”强调的是内容积累和分发。也就是说平台需要通过标签、分类、搜索、排行榜、推荐这些手段把零散的文章、视频、课件“汇集”到用户面前。光有上传没有分发内容再多也没人看。这个模块群需要重点设计的是内容元数据标题、摘要、封面图、标签、所属分类、发布时间、浏览量、点赞量、收藏量、作者信息。之后所有搜索、推荐、排行都建立在字段设计是否合理之上。我见过不少同学把标签直接拼在一个字符串字段里导致后来想按标签做推荐时完全没法查只能返工。1.3 “媒学坊”创作教学与学习轨迹“坊”更像一个工作室或课堂。这个模块群把平台从“内容仓库”升级成“教学系统”讲师可以创建课程把课程拆成章节和课时课时里放图文或视频学生可以报名课程记录学习进度完成课时后标记为已学最后看到自己的课程完成度。这里最大的坑是“进度跟踪”。如果你只在课程表里存一个“学完/未学完”那用户看到一半关闭页面再进来就不知道该从哪继续了。合理的做法是建一张学习进度表记录“哪个用户、哪个课时、看到哪一秒/读过第几节、最近一次更新时间”才能支撑“继续学习”的体验。1.4 角色与权限三类用户对应的操作边界把所有功能列出来后你会发现权限问题绕不开。这套系统至少有三类角色角色核心操作普通用户浏览内容、搜索、点赞收藏评论、学习课程、维护个人资料创作者/讲师发布文章、上传视频、创建课程、管理自己内容、查看数据管理员内容审核、用户管理、分类/标签管理、数据统计毕设里用Spring Security或者Sa-Token做一套RBAC基于角色的访问控制就够了不需要太复杂。但有一点必须做接口要校验“当前登录用户有没有权限操作这个资源”比如只有作者本人能修改自己的文章管理员能下架任何人的违规内容。很多初版代码只校验了“有没有登录”没校验“是不是本人”答辩时被评委问一句“我登录A用户能不能改B用户的文章”就会卡住。2. 技术栈选型Spring Boot MyBatis-Plus 为主微服务不要碰Java毕设最容易掉进两个极端一是用JSPServlet写老古董二是上来就拆微服务跟Spring Cloud硬磕。这两种我都不推荐。前者配置繁琐、前后端不分代码写起来很痛苦后者光环境搭建就要折腾一周对毕设来说性价比极低。2.1 后端Spring Boot MyBatis-Plus Redis MySQL这个组合基本是当前Java毕设的主流答案。Spring Boot负责把配置和启动简化掉MyBatis-Plus帮你在单表操作上省掉大量重复SQLMySQL存业务数据Redis做缓存和热点计数。鉴权方案用JWT比Session更适合前后端分离因为后端不需要维护会话状态前端把Token存在本地存储里请求时放到请求头就行。2.2 前端Vue3 Element Plus Axios ViteVue3配合Element Plus做后台管理系统和用户端页面都很快组件库齐全表格、表单、上传、分页这些都是现成的。Axios负责请求Vite启动比Webpack舒服很多。如果要做视频播放用原生video标签配一个合适的播放器组件即可如果视频格式兼容性不好可以引入hls.js处理m3u8流。2.3 工程结构怎么划分我建议按“单一模块、包内分层”来做不拆微服务。后端工程大致这样分包com.example.zxq ├── controller # 接口层 ├── service # 业务层接口实现 ├── mapper # 数据访问层 ├── entity # 数据库实体 ├── dto / vo # 请求参数 和 返回视图对象 ├── config # 配置类Redis、拦载器、跨域 ├── common # 统一返回结构、异常处理、工具类 └── util # 工具这样的结构在答辩时很容易讲清楚Controller只做参数接收和结果返回业务逻辑在Service里数据库操作在Mapper层。评委看到包结构就能判断出你有没有基本的工程意识。2.4 为什么不用微服务、不用Elasticsearch有些同学觉得系统叫“知识共享平台”搜索和推荐一定要用Elasticsearch。我的建议是除非你精力非常充足否则不要给自己加戏。用MySQL的LIKE查询配合合理的索引在演示数据和几千条数据量级下完全够用。推荐也一样写一个基于标签匹配和热度加权的简单算法比接一套复杂的推荐中间件更能体现你的理解。3. 数据库设计不只四张核心表还要补齐行为数据表很多同学建表只建了用户表、内容表、课程表、评论表就开工了结果做到一半发现“收藏记录没地方存”“学习进度不知道放哪”“点赞状态查不到”。问题不在编码而在起步时表设计漏了行为数据。3.1 用户与内容相关表用户表除了基础字段建议加上头像、个人简介、积分/等级、创建时间内容区分图文和视频两类可以用一张表加type字段也可以用两张表分别存。我更喜欢一张主表存公共信息标题、封面、摘要、分类、标签、作者、状态、浏览量再根据内容类型扩展字段因为搜索、列表展示都只需要一张表复用性最好。3.2 互动行为表点赞、收藏、关注这些行为一定要单独建表不要只堆数字。原因很简单用户“点过赞之后再次点击取消赞”前端需要知道当前用户对这条内容是否点过赞。如果只存总数这个状态就判断不了。所以需要类似点赞记录表每次查询时先查记录再决定按钮显示“已点赞”还是“点赞”。3.3 课程教学相关表课程表与章节表、课时表是典型的一对多关系。课程包含多个章节章节包含多个课时。还要有一张课程报名表或学习记录表记录用户是否加入课程加入时间。学习进度表则记录每个课时用户看到的位置或完成状态。3.4 核心建表SQL参考简化版下面给出一份简化版但足够支撑系统主流程的建表SQL字段命名以实际项目为准这里重点是展示表之间的关系-- 用户表 CREATE TABLE user ( id BIGINT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL UNIQUE, password VARCHAR(100) NOT NULL, nickname VARCHAR(50), avatar VARCHAR(255), role TINYINT DEFAULT 1, -- 1普通用户 2创作者 3管理员 status TINYINT DEFAULT 1, -- 1正常 0禁用 create_time DATETIME, update_time DATETIME ); -- 内容/视频表 CREATE TABLE content ( id BIGINT PRIMARY KEY AUTO_INCREMENT, title VARCHAR(100) NOT NULL, summary VARCHAR(255), cover VARCHAR(255), content_type TINYINT, -- 1图文 2视频 body TEXT, -- 富文本内容 video_url VARCHAR(255), -- 视频地址 category_id BIGINT, tags VARCHAR(255), -- 多个标签用逗号分隔 author_id BIGINT, status TINYINT DEFAULT 0, -- 0待审核 1已发布 2已下架 view_count INT DEFAULT 0, like_count INT DEFAULT 0, favorite_count INT DEFAULT 0, create_time DATETIME, update_time DATETIME, KEY idx_author (author_id), KEY idx_category (category_id), KEY idx_status (status) ); -- 点赞记录表 CREATE TABLE like_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT, content_id BIGINT, create_time DATETIME, UNIQUE KEY uk_user_content (user_id, content_id) ); -- 课程表 CREATE TABLE course ( id BIGINT PRIMARY KEY AUTO_INCREMENT, title VARCHAR(100), cover VARCHAR(255), description TEXT, teacher_id BIGINT, status TINYINT DEFAULT 0, create_time DATETIME ); -- 章节表 CREATE TABLE chapter ( id BIGINT PRIMARY KEY AUTO_INCREMENT, course_id BIGINT, title VARCHAR(100), sort INT ); -- 课时表 CREATE TABLE lesson ( id BIGINT PRIMARY KEY AUTO_INCREMENT, chapter_id BIGINT, title VARCHAR(100), video_url VARCHAR(255), content TEXT, sort INT ); -- 学习进度表 CREATE TABLE study_progress ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT, lesson_id BIGINT, progress INT DEFAULT 0, -- 0未学 1学习中 2已完成 last_position INT DEFAULT 0, -- 视频播放位置单位秒 update_time DATETIME, UNIQUE KEY uk_user_lesson (user_id, lesson_id) );这里尤其要注意两点点赞记录表的唯一索引user_id, content_id能防止同一用户对同一条内容重复点赞学习进度表的唯一索引user_id, lesson_id能保证一个用户在一个课时里只保留一条进度记录后续更新就行不用重复插入。3.5 状态字段统一用Tinyint时间字段别省内容状态、用户状态、课程状态这些字段建议统一用0/1/2/3这样的数字不要用字符串。一来数据库存储更轻二来代码里可以写成枚举可读性更好。另一个容易被忽视的是create_time和update_time几乎每张业务表都需要MyBatis-Plus里用TableField(fill FieldFill.INSERT)和TableField(fill FieldFill.INSERT_UPDATE)可以自动填充省事又统一。4. 关键功能落地内容发布、视频上传、搜索推荐、学习轨迹数据库设计好之后开发顺序也很重要。我习惯按“一条核心链路”推进用户进来 → 看到内容列表 → 点进详情 → 点赞收藏评论 → 学习课程 → 创作者发布内容 → 管理员审核 → 正常展示。这条链路走通系统就能演示了。4.1 内容发布与审核状态机创作者在前端提交文章或视频时不要直接进入已发布状态。所有内容先落到“待审核”管理员在后台审核通过后才变成“已发布”否则进入“已驳回”或“已下架”。这样做看起来很“学生”但恰恰是评委喜欢看到的业务闭环。后端实现上只需要一个状态字段加两个接口创建内容时status0管理员调用审核接口时传入contentId和审核结果通过就更新为1驳回就更新为2。MyBatis-Plus更新单条记录非常简单// 伪代码演示审核逻辑 public Boolean auditContent(Long contentId, Integer status) { Content content contentMapper.selectById(contentId); if (content null) { throw new RuntimeException(内容不存在); } content.setStatus(status); // 1通过 2驳回 content.setUpdateTime(LocalDateTime.now()); return contentMapper.updateById(content) 0; }4.2 视频上传与文件存储本地存储即可但路径要规范很多同学一上来就研究分片上传、秒传、断点续传结果卡了好几天。毕设阶段用MultipartFile接收文件、校验文件大小和类型、重命名后保存到本地目录再通过一个Handler映射做静态资源访问完全够用。重命名时不要用原始文件名因为可能包含中文或特殊字符。我一般用UUID加后缀String originalFilename file.getOriginalFilename(); String ext originalFilename.substring(originalFilename.lastIndexOf(.)); String filename UUID.randomUUID().toString().replace(-, ) ext;文件保存到本地后不要直接把磁盘绝对路径存进数据库否则项目换位置后全部失效。更稳的做法是存相对路径比如“/upload/video/xxx.mp4”然后通过配置映射到实际目录前端直接用站点域名加这个相对路径访问。4.3 搜索与前端列表LIKE查询的代价与轻量优化标题里带了“搜索”隐含需求正文里的搜索框也要实现。用MySQL的LIKE模糊匹配是最直接的做法SELECT * FROM content WHERE title LIKE CONCAT(%, #{keyword}, %) OR tags LIKE CONCAT(%, #{keyword}, %) ORDER BY view_count DESC这个方案的缺点是当数据量大时会全表扫描。在毕设阶段数据量不大可以接受。但如果你想给自己加分可以做一个很轻量的优化把分类和标签单独建表搜索时先通过标签表查出相关内容的ID集合再用IN查询内容表。这样既避免了LIKE大范围扫描也让标签体系更规范。4.4 推荐算法的“毕设级”实现热度分加标签匹配推荐不一定要用协同过滤毕设完全可以用一个可解释的评分公式。我的做法是给每条内容算一个“热度分”和一个“匹配分”最终得分由两者加权。// 伪代码热度分计算 double hotScore viewCount * 0.3 likeCount * 0.5 favoriteCount * 0.8 commentCount * 0.7; // 时间衰减最近发布的适当加权 long hours ChronoUnit.HOURS.between(createTime, LocalDateTime.now()); hotScore hotScore / (1 hours * 0.001);再结合用户感兴趣的标签如果内容标签命中用户最近操作过的标签匹配分就加固定权重。这样推荐结果既有热度基础又跟用户行为相关评委问起来也能讲清楚逻辑。4.5 学习进度从“已学”到“学到哪了”课程学习的体验重点不在课程列表而在“继续学习”按钮。实现思路是用户打开某个课时时前端记录开始时间播放视频时定时上报当前播放秒数点击“完成学习”或视频播完后端把progress置为2进入课程页面时查询该用户所有学习进度如果存在progress1的记录就展示“上次学到第几章第几节”。这个流程涉及三个接口查进度、更新进度、完成课时。对应前端视频的timeupdate事件和后端更新接口。学习进度表还有一个好处课程页能统计完成度已完成课时数除以总课时数直接展示百分比进度条这是课程类系统的核心亮点。5. 开发过程中最容易踩的坑我先踩过再帮你描一遍这一路调试过来有几个坑几乎每次都会遇到。提前知道了能省好几个晚上。5.1 Swagger或接口测试正常但前端一调就跨域前后端分离项目最常见的报错就是CORS。如果你用JWT并且后端配置了跨域但前端请求带上了Authorization头记得跨域配置里allowedHeaders要允许Authorization字段allowedMethods里也要包含OPTIONS。很多同学的配置只允许了GET和POST结果PUT、DELETE接口在浏览器里直接挂掉。5.2 本地文件上传成功刷新后访问不了问题几乎都出在静态资源映射上。后端写了文件保存逻辑但忘了把本地磁盘目录映射为可访问URL。Spring Boot里加一段配置就行Configuration public class WebConfig implements WebMvcConfigurer { Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/upload/**) .addResourceLocations(file: uploadPath); } }路径变量不要硬编码在代码里放到application.yml配置里。否则换一台机器运行整个网站图片视频全挂这事我见过太多次了。5.3 用Redis存点赞数结果跟数据库对不上为了性能把点赞数先更新Redis再异步同步到MySQL这套思路本身没错但是毕设项目事务链路不长异步同步反而容易出乱子。我的建议是点赞记录表直接写MySQL同时用Redis做缓存缓存内容详情删除或更新缓存时重新查库。对于几万条数据MySQL的更新压力完全不是瓶颈别为了“显得高级”引入不必要的复杂度。5.4 前端路由刷新404如果用的是Vue Router的history模式部署到Tomcat后刷新子页面会404因为Tomcat找不到前端路由对应的后端路径。最简单的解决办法是用hash模式地址栏会带个#但不用任何配置或者部署后端的转发规则把所有非/upload和/api的请求转发到index.html。毕设演示为了省事直接用hash模式最稳。常见问题现象解决思路跨域请求失败浏览器控制台CORS报错检查OPTIONS和Authorization头上传图片无法访问页面图片404配置静态资源映射视频播不了视频请求返回206或404检查文件路径和服务器Range支持前端刷新404子页面直接白屏用hash模式或统一转发点赞状态错乱查询时不知道用户是否点过赞用点赞记录表不只看总数5.5 视频播放的坑别让评委体验卡在“黑屏”很多人用本地视频文件放Tomcat后浏览器播放经常遇到拖动进度条请求206 Range的问题。解决方法是确认后端静态资源处理器支持Range请求或者干脆在前端引入支持HLS的播放方式。如果视频来源是本地上传的mp4建议转成m3u8切片再播放体验更稳定也能体现你对流媒体基础原理的理解。当然这一步是优化项不是必须项。6. 演示与答辩准备让系统从“能跑”变成“能讲”代码写完了最后一步是把项目包装成可以在评委面前流畅演示的作品。我看到过不少人代码没问题但演示时手忙脚乱、数据一片空白给评委的印象大打折扣。准备演示比你想的更重要。6.1 准备一批有真实感的演示数据不要在空数据库里演示。准备一个数据初始化脚本包含至少8-10个用户账号有昵称、头像、简介50条以上内容文章视频各一半标题像正常文章比如“新手怎么从零开始做短视频剪辑”“公众号排版避坑指南”3-4门课程每门课程至少2个章节、每个章节至少2个课时每条内容都有一定浏览量和点赞量。这些数据能让首页分类、搜索、排行榜、推荐列表都有内容可展示。6.2 配置三套演示账号用普通用户身份演示从浏览到学习再到提问的全流程用创作者身份演示发布内容用管理员身份演示审核和内容管理。三个账号穿插演示能完整展示整个系统的闭环。每切换一个角色时先清空浏览器缓存和登录状态避免Token串角色。演示顺序推荐管理员先登录在后台审核一条内容 → 普通用户浏览首页搜索关键词进详情页点赞收藏评论 → 进入课程目录接着上次进度继续学习 → 创作者登录新建一篇文章上传一张封面提交审核 → 回到管理员后台审核通过后刷新前端看到内容上架。这样一条线下来前后端所有核心模块都覆盖到了。6.3 高频答辩问题怎么接答辨时评委的问题往往集中在几个点为什么选这套技术方案权限怎么做搜索怎么实现推荐算法怎么实现的学习进度怎么存这些问题的答案其实都在前面代码里关键是你要捋清回答的逻辑。先答设计思路再答具体实现最后补一句“当时的限制和后续优化方向”。比如问搜索先讲毕设阶段用MySQL LIKE查询能保证结果可用再讲如果数据量大了可以引入全文检索中间件分层演进。这样既诚实又有深度。6.4 给系统加两个“小而亮”的加分功能如果时间允许我建议加两个轻量级功能一个数据可视化面板统计每日新增用户数、内容发布数、视频播放量用图表组件展示接口只需要按日期做GROUP BY统计另一个是创作者中心的“我的数据”页展示自己所有内容的浏览总量、点赞总量、课程学习人数。这些功能逻辑简单但特别能提升项目的完成度和“作品感”。最后说点实际的我做过的这类教学平台模拟项目不算少最深刻的体会是毕设不是比谁功能清单长而是比谁能把一条核心链路做完整。你哪怕只做了用户、内容、课程、进度这四个模块只要链路走得通、数据一致、界面不粗糙就已经是一份合格的作品。最后再分享一个小技巧演示之前把所有Redis缓存和本地临时数据清一遍用初始化脚本重新灌入数据然后按事先准备的三条账号线完整走一遍流程。这个“彩排”动作至少能提前暴露80%的现场翻车问题。我帮学生调试时最常说的就是一句话——数据库一初始化、演示脚本一跑、评委一问“为什么”基本就能看出这个项目是不是自己做的、做没做通。祝开工顺利。
最近帮某高校的几个学生看毕设发现一个特别典型的选题方向题目又长又绕一口气挂了三个系统名——“智享圈”新媒体学习网站、“智汇云”新媒体知识共享平台、“媒学坊”数字内容创作教学系统。乍一看以为是三个项目其实是一条需求拆出来的一个系统只是站方给了三种叫法说白了一个网上学习平台既要能看文章视频、又要能开课教学、还得让用户之间产生互动和知识沉淀。这种题目在Java毕设里属于“看着简单、做着发懵”的类型功能似乎都是常规CRUD但真把需求落到表结构、接口和前端页面上很多人会卡在“不知道先做什么、后做什么”以及“做出来像一堆零散页面不像一个完整产品”。这篇就按我实际跟学生调试时用的思路把这类题目从拆题、选型、数据库设计到核心实现和答辩准备完整过一遍给还没开工或者已经写了一半代码的同学做个参考。1. 三个名字不是随便起的先把业务角色和模块边界理清楚毕设第一步不是写代码而是把题目里的每个词翻译成功能需求。这三个名字如果拆开看其实对应了三个模块群它们之间有交集但关注点不同。1.1 “智享圈”社区与互动“圈”字暗示的是人际关系和内容流动。一个新媒体学习网站如果只有内容没有评论、点赞、收藏、关注那就只是个单向展示的“橱窗”撑不起“学习圈”这个概念。所以第一个模块群一定包含用户注册登录、个人主页、关注/粉丝、内容浏览、点赞、收藏、评论回复、私信或站内通知。这些功能对毕设来说不是难点但要注意它们之间的关联评论要有评论者和内容ID点赞要处理“点过再点取消”的状态收藏要有分类标签关注要影响信息流。如果只把表建出来不做关联界面会很散。1.2 “智汇云”知识共享与聚合“云”和“汇”强调的是内容积累和分发。也就是说平台需要通过标签、分类、搜索、排行榜、推荐这些手段把零散的文章、视频、课件“汇集”到用户面前。光有上传没有分发内容再多也没人看。这个模块群需要重点设计的是内容元数据标题、摘要、封面图、标签、所属分类、发布时间、浏览量、点赞量、收藏量、作者信息。之后所有搜索、推荐、排行都建立在字段设计是否合理之上。我见过不少同学把标签直接拼在一个字符串字段里导致后来想按标签做推荐时完全没法查只能返工。1.3 “媒学坊”创作教学与学习轨迹“坊”更像一个工作室或课堂。这个模块群把平台从“内容仓库”升级成“教学系统”讲师可以创建课程把课程拆成章节和课时课时里放图文或视频学生可以报名课程记录学习进度完成课时后标记为已学最后看到自己的课程完成度。这里最大的坑是“进度跟踪”。如果你只在课程表里存一个“学完/未学完”那用户看到一半关闭页面再进来就不知道该从哪继续了。合理的做法是建一张学习进度表记录“哪个用户、哪个课时、看到哪一秒/读过第几节、最近一次更新时间”才能支撑“继续学习”的体验。1.4 角色与权限三类用户对应的操作边界把所有功能列出来后你会发现权限问题绕不开。这套系统至少有三类角色角色核心操作普通用户浏览内容、搜索、点赞收藏评论、学习课程、维护个人资料创作者/讲师发布文章、上传视频、创建课程、管理自己内容、查看数据管理员内容审核、用户管理、分类/标签管理、数据统计毕设里用Spring Security或者Sa-Token做一套RBAC基于角色的访问控制就够了不需要太复杂。但有一点必须做接口要校验“当前登录用户有没有权限操作这个资源”比如只有作者本人能修改自己的文章管理员能下架任何人的违规内容。很多初版代码只校验了“有没有登录”没校验“是不是本人”答辩时被评委问一句“我登录A用户能不能改B用户的文章”就会卡住。2. 技术栈选型Spring Boot MyBatis-Plus 为主微服务不要碰Java毕设最容易掉进两个极端一是用JSPServlet写老古董二是上来就拆微服务跟Spring Cloud硬磕。这两种我都不推荐。前者配置繁琐、前后端不分代码写起来很痛苦后者光环境搭建就要折腾一周对毕设来说性价比极低。2.1 后端Spring Boot MyBatis-Plus Redis MySQL这个组合基本是当前Java毕设的主流答案。Spring Boot负责把配置和启动简化掉MyBatis-Plus帮你在单表操作上省掉大量重复SQLMySQL存业务数据Redis做缓存和热点计数。鉴权方案用JWT比Session更适合前后端分离因为后端不需要维护会话状态前端把Token存在本地存储里请求时放到请求头就行。2.2 前端Vue3 Element Plus Axios ViteVue3配合Element Plus做后台管理系统和用户端页面都很快组件库齐全表格、表单、上传、分页这些都是现成的。Axios负责请求Vite启动比Webpack舒服很多。如果要做视频播放用原生video标签配一个合适的播放器组件即可如果视频格式兼容性不好可以引入hls.js处理m3u8流。2.3 工程结构怎么划分我建议按“单一模块、包内分层”来做不拆微服务。后端工程大致这样分包com.example.zxq ├── controller # 接口层 ├── service # 业务层接口实现 ├── mapper # 数据访问层 ├── entity # 数据库实体 ├── dto / vo # 请求参数 和 返回视图对象 ├── config # 配置类Redis、拦载器、跨域 ├── common # 统一返回结构、异常处理、工具类 └── util # 工具这样的结构在答辩时很容易讲清楚Controller只做参数接收和结果返回业务逻辑在Service里数据库操作在Mapper层。评委看到包结构就能判断出你有没有基本的工程意识。2.4 为什么不用微服务、不用Elasticsearch有些同学觉得系统叫“知识共享平台”搜索和推荐一定要用Elasticsearch。我的建议是除非你精力非常充足否则不要给自己加戏。用MySQL的LIKE查询配合合理的索引在演示数据和几千条数据量级下完全够用。推荐也一样写一个基于标签匹配和热度加权的简单算法比接一套复杂的推荐中间件更能体现你的理解。3. 数据库设计不只四张核心表还要补齐行为数据表很多同学建表只建了用户表、内容表、课程表、评论表就开工了结果做到一半发现“收藏记录没地方存”“学习进度不知道放哪”“点赞状态查不到”。问题不在编码而在起步时表设计漏了行为数据。3.1 用户与内容相关表用户表除了基础字段建议加上头像、个人简介、积分/等级、创建时间内容区分图文和视频两类可以用一张表加type字段也可以用两张表分别存。我更喜欢一张主表存公共信息标题、封面、摘要、分类、标签、作者、状态、浏览量再根据内容类型扩展字段因为搜索、列表展示都只需要一张表复用性最好。3.2 互动行为表点赞、收藏、关注这些行为一定要单独建表不要只堆数字。原因很简单用户“点过赞之后再次点击取消赞”前端需要知道当前用户对这条内容是否点过赞。如果只存总数这个状态就判断不了。所以需要类似点赞记录表每次查询时先查记录再决定按钮显示“已点赞”还是“点赞”。3.3 课程教学相关表课程表与章节表、课时表是典型的一对多关系。课程包含多个章节章节包含多个课时。还要有一张课程报名表或学习记录表记录用户是否加入课程加入时间。学习进度表则记录每个课时用户看到的位置或完成状态。3.4 核心建表SQL参考简化版下面给出一份简化版但足够支撑系统主流程的建表SQL字段命名以实际项目为准这里重点是展示表之间的关系-- 用户表 CREATE TABLE user ( id BIGINT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL UNIQUE, password VARCHAR(100) NOT NULL, nickname VARCHAR(50), avatar VARCHAR(255), role TINYINT DEFAULT 1, -- 1普通用户 2创作者 3管理员 status TINYINT DEFAULT 1, -- 1正常 0禁用 create_time DATETIME, update_time DATETIME ); -- 内容/视频表 CREATE TABLE content ( id BIGINT PRIMARY KEY AUTO_INCREMENT, title VARCHAR(100) NOT NULL, summary VARCHAR(255), cover VARCHAR(255), content_type TINYINT, -- 1图文 2视频 body TEXT, -- 富文本内容 video_url VARCHAR(255), -- 视频地址 category_id BIGINT, tags VARCHAR(255), -- 多个标签用逗号分隔 author_id BIGINT, status TINYINT DEFAULT 0, -- 0待审核 1已发布 2已下架 view_count INT DEFAULT 0, like_count INT DEFAULT 0, favorite_count INT DEFAULT 0, create_time DATETIME, update_time DATETIME, KEY idx_author (author_id), KEY idx_category (category_id), KEY idx_status (status) ); -- 点赞记录表 CREATE TABLE like_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT, content_id BIGINT, create_time DATETIME, UNIQUE KEY uk_user_content (user_id, content_id) ); -- 课程表 CREATE TABLE course ( id BIGINT PRIMARY KEY AUTO_INCREMENT, title VARCHAR(100), cover VARCHAR(255), description TEXT, teacher_id BIGINT, status TINYINT DEFAULT 0, create_time DATETIME ); -- 章节表 CREATE TABLE chapter ( id BIGINT PRIMARY KEY AUTO_INCREMENT, course_id BIGINT, title VARCHAR(100), sort INT ); -- 课时表 CREATE TABLE lesson ( id BIGINT PRIMARY KEY AUTO_INCREMENT, chapter_id BIGINT, title VARCHAR(100), video_url VARCHAR(255), content TEXT, sort INT ); -- 学习进度表 CREATE TABLE study_progress ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT, lesson_id BIGINT, progress INT DEFAULT 0, -- 0未学 1学习中 2已完成 last_position INT DEFAULT 0, -- 视频播放位置单位秒 update_time DATETIME, UNIQUE KEY uk_user_lesson (user_id, lesson_id) );这里尤其要注意两点点赞记录表的唯一索引user_id, content_id能防止同一用户对同一条内容重复点赞学习进度表的唯一索引user_id, lesson_id能保证一个用户在一个课时里只保留一条进度记录后续更新就行不用重复插入。3.5 状态字段统一用Tinyint时间字段别省内容状态、用户状态、课程状态这些字段建议统一用0/1/2/3这样的数字不要用字符串。一来数据库存储更轻二来代码里可以写成枚举可读性更好。另一个容易被忽视的是create_time和update_time几乎每张业务表都需要MyBatis-Plus里用TableField(fill FieldFill.INSERT)和TableField(fill FieldFill.INSERT_UPDATE)可以自动填充省事又统一。4. 关键功能落地内容发布、视频上传、搜索推荐、学习轨迹数据库设计好之后开发顺序也很重要。我习惯按“一条核心链路”推进用户进来 → 看到内容列表 → 点进详情 → 点赞收藏评论 → 学习课程 → 创作者发布内容 → 管理员审核 → 正常展示。这条链路走通系统就能演示了。4.1 内容发布与审核状态机创作者在前端提交文章或视频时不要直接进入已发布状态。所有内容先落到“待审核”管理员在后台审核通过后才变成“已发布”否则进入“已驳回”或“已下架”。这样做看起来很“学生”但恰恰是评委喜欢看到的业务闭环。后端实现上只需要一个状态字段加两个接口创建内容时status0管理员调用审核接口时传入contentId和审核结果通过就更新为1驳回就更新为2。MyBatis-Plus更新单条记录非常简单// 伪代码演示审核逻辑 public Boolean auditContent(Long contentId, Integer status) { Content content contentMapper.selectById(contentId); if (content null) { throw new RuntimeException(内容不存在); } content.setStatus(status); // 1通过 2驳回 content.setUpdateTime(LocalDateTime.now()); return contentMapper.updateById(content) 0; }4.2 视频上传与文件存储本地存储即可但路径要规范很多同学一上来就研究分片上传、秒传、断点续传结果卡了好几天。毕设阶段用MultipartFile接收文件、校验文件大小和类型、重命名后保存到本地目录再通过一个Handler映射做静态资源访问完全够用。重命名时不要用原始文件名因为可能包含中文或特殊字符。我一般用UUID加后缀String originalFilename file.getOriginalFilename(); String ext originalFilename.substring(originalFilename.lastIndexOf(.)); String filename UUID.randomUUID().toString().replace(-, ) ext;文件保存到本地后不要直接把磁盘绝对路径存进数据库否则项目换位置后全部失效。更稳的做法是存相对路径比如“/upload/video/xxx.mp4”然后通过配置映射到实际目录前端直接用站点域名加这个相对路径访问。4.3 搜索与前端列表LIKE查询的代价与轻量优化标题里带了“搜索”隐含需求正文里的搜索框也要实现。用MySQL的LIKE模糊匹配是最直接的做法SELECT * FROM content WHERE title LIKE CONCAT(%, #{keyword}, %) OR tags LIKE CONCAT(%, #{keyword}, %) ORDER BY view_count DESC这个方案的缺点是当数据量大时会全表扫描。在毕设阶段数据量不大可以接受。但如果你想给自己加分可以做一个很轻量的优化把分类和标签单独建表搜索时先通过标签表查出相关内容的ID集合再用IN查询内容表。这样既避免了LIKE大范围扫描也让标签体系更规范。4.4 推荐算法的“毕设级”实现热度分加标签匹配推荐不一定要用协同过滤毕设完全可以用一个可解释的评分公式。我的做法是给每条内容算一个“热度分”和一个“匹配分”最终得分由两者加权。// 伪代码热度分计算 double hotScore viewCount * 0.3 likeCount * 0.5 favoriteCount * 0.8 commentCount * 0.7; // 时间衰减最近发布的适当加权 long hours ChronoUnit.HOURS.between(createTime, LocalDateTime.now()); hotScore hotScore / (1 hours * 0.001);再结合用户感兴趣的标签如果内容标签命中用户最近操作过的标签匹配分就加固定权重。这样推荐结果既有热度基础又跟用户行为相关评委问起来也能讲清楚逻辑。4.5 学习进度从“已学”到“学到哪了”课程学习的体验重点不在课程列表而在“继续学习”按钮。实现思路是用户打开某个课时时前端记录开始时间播放视频时定时上报当前播放秒数点击“完成学习”或视频播完后端把progress置为2进入课程页面时查询该用户所有学习进度如果存在progress1的记录就展示“上次学到第几章第几节”。这个流程涉及三个接口查进度、更新进度、完成课时。对应前端视频的timeupdate事件和后端更新接口。学习进度表还有一个好处课程页能统计完成度已完成课时数除以总课时数直接展示百分比进度条这是课程类系统的核心亮点。5. 开发过程中最容易踩的坑我先踩过再帮你描一遍这一路调试过来有几个坑几乎每次都会遇到。提前知道了能省好几个晚上。5.1 Swagger或接口测试正常但前端一调就跨域前后端分离项目最常见的报错就是CORS。如果你用JWT并且后端配置了跨域但前端请求带上了Authorization头记得跨域配置里allowedHeaders要允许Authorization字段allowedMethods里也要包含OPTIONS。很多同学的配置只允许了GET和POST结果PUT、DELETE接口在浏览器里直接挂掉。5.2 本地文件上传成功刷新后访问不了问题几乎都出在静态资源映射上。后端写了文件保存逻辑但忘了把本地磁盘目录映射为可访问URL。Spring Boot里加一段配置就行Configuration public class WebConfig implements WebMvcConfigurer { Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/upload/**) .addResourceLocations(file: uploadPath); } }路径变量不要硬编码在代码里放到application.yml配置里。否则换一台机器运行整个网站图片视频全挂这事我见过太多次了。5.3 用Redis存点赞数结果跟数据库对不上为了性能把点赞数先更新Redis再异步同步到MySQL这套思路本身没错但是毕设项目事务链路不长异步同步反而容易出乱子。我的建议是点赞记录表直接写MySQL同时用Redis做缓存缓存内容详情删除或更新缓存时重新查库。对于几万条数据MySQL的更新压力完全不是瓶颈别为了“显得高级”引入不必要的复杂度。5.4 前端路由刷新404如果用的是Vue Router的history模式部署到Tomcat后刷新子页面会404因为Tomcat找不到前端路由对应的后端路径。最简单的解决办法是用hash模式地址栏会带个#但不用任何配置或者部署后端的转发规则把所有非/upload和/api的请求转发到index.html。毕设演示为了省事直接用hash模式最稳。常见问题现象解决思路跨域请求失败浏览器控制台CORS报错检查OPTIONS和Authorization头上传图片无法访问页面图片404配置静态资源映射视频播不了视频请求返回206或404检查文件路径和服务器Range支持前端刷新404子页面直接白屏用hash模式或统一转发点赞状态错乱查询时不知道用户是否点过赞用点赞记录表不只看总数5.5 视频播放的坑别让评委体验卡在“黑屏”很多人用本地视频文件放Tomcat后浏览器播放经常遇到拖动进度条请求206 Range的问题。解决方法是确认后端静态资源处理器支持Range请求或者干脆在前端引入支持HLS的播放方式。如果视频来源是本地上传的mp4建议转成m3u8切片再播放体验更稳定也能体现你对流媒体基础原理的理解。当然这一步是优化项不是必须项。6. 演示与答辩准备让系统从“能跑”变成“能讲”代码写完了最后一步是把项目包装成可以在评委面前流畅演示的作品。我看到过不少人代码没问题但演示时手忙脚乱、数据一片空白给评委的印象大打折扣。准备演示比你想的更重要。6.1 准备一批有真实感的演示数据不要在空数据库里演示。准备一个数据初始化脚本包含至少8-10个用户账号有昵称、头像、简介50条以上内容文章视频各一半标题像正常文章比如“新手怎么从零开始做短视频剪辑”“公众号排版避坑指南”3-4门课程每门课程至少2个章节、每个章节至少2个课时每条内容都有一定浏览量和点赞量。这些数据能让首页分类、搜索、排行榜、推荐列表都有内容可展示。6.2 配置三套演示账号用普通用户身份演示从浏览到学习再到提问的全流程用创作者身份演示发布内容用管理员身份演示审核和内容管理。三个账号穿插演示能完整展示整个系统的闭环。每切换一个角色时先清空浏览器缓存和登录状态避免Token串角色。演示顺序推荐管理员先登录在后台审核一条内容 → 普通用户浏览首页搜索关键词进详情页点赞收藏评论 → 进入课程目录接着上次进度继续学习 → 创作者登录新建一篇文章上传一张封面提交审核 → 回到管理员后台审核通过后刷新前端看到内容上架。这样一条线下来前后端所有核心模块都覆盖到了。6.3 高频答辩问题怎么接答辨时评委的问题往往集中在几个点为什么选这套技术方案权限怎么做搜索怎么实现推荐算法怎么实现的学习进度怎么存这些问题的答案其实都在前面代码里关键是你要捋清回答的逻辑。先答设计思路再答具体实现最后补一句“当时的限制和后续优化方向”。比如问搜索先讲毕设阶段用MySQL LIKE查询能保证结果可用再讲如果数据量大了可以引入全文检索中间件分层演进。这样既诚实又有深度。6.4 给系统加两个“小而亮”的加分功能如果时间允许我建议加两个轻量级功能一个数据可视化面板统计每日新增用户数、内容发布数、视频播放量用图表组件展示接口只需要按日期做GROUP BY统计另一个是创作者中心的“我的数据”页展示自己所有内容的浏览总量、点赞总量、课程学习人数。这些功能逻辑简单但特别能提升项目的完成度和“作品感”。最后说点实际的我做过的这类教学平台模拟项目不算少最深刻的体会是毕设不是比谁功能清单长而是比谁能把一条核心链路做完整。你哪怕只做了用户、内容、课程、进度这四个模块只要链路走得通、数据一致、界面不粗糙就已经是一份合格的作品。最后再分享一个小技巧演示之前把所有Redis缓存和本地临时数据清一遍用初始化脚本重新灌入数据然后按事先准备的三条账号线完整走一遍流程。这个“彩排”动作至少能提前暴露80%的现场翻车问题。我帮学生调试时最常说的就是一句话——数据库一初始化、演示脚本一跑、评委一问“为什么”基本就能看出这个项目是不是自己做的、做没做通。祝开工顺利。
