这几天又有人私信我：毕业设计到底做什么题好？说实话，每次看到“XX管理系统”“XX商城”这类题目，我都想多问一句：你要是答辩老师，连续看了八个一模一样的管理系统，还会觉得这个选题有价值吗？我自己去年做的是“基于Nodejs和Vue框架的短剧推荐系统设计与实现”，从选题、搭框架、调推荐算法、写论文到准备答辩，整个过程踩了不少坑，今天就把完整的从0到1思路整理出来。
这篇内容覆盖几个关键点：短剧推荐系统的需求怎么拆、Node.js + Vue这套组合为什么适合做毕设项目、推荐算法（标签向量相似度、UserCF协同过滤、混合排序）代码级怎么落地、m3u8分集播放怎么接、环境配置阶段几乎人人会遇到的npm和PowerShell报错怎么处理，以及论文的创新点应该怎么写。适合两类人看：一类是正在纠结毕业设计选题的计算机相关专业学生，另一类是打算自学Node.js和Vue全栈、想用一个完整项目练手的开发者。
1. 为什么我劝你今年别再选“XX管理系统”了：短剧推荐系统的选题价值拆解
1.1 短剧内容消费的推荐逻辑和长视频完全不同
短剧这几年的增长速度，不用我多说了。单集一两分钟、竖屏、节奏极快，用户刷起来是一集接一集，根本停不下来。这种内容形态和传统长视频最大的区别在于：用户很少主动搜索，而是高度依赖平台“推什么看什么”。
长视频平台用户有明确的剧名记忆，想看《某某传》会自己去搜；短剧用户记住的是“那个霸总的”“那个穿越的”，内容本身高度同质化，唯一能帮用户做筛选的就是推荐系统。所以短剧平台的核心竞争力，一半在内容供给，另一半就在推荐分发。这一行业背景放到毕业设计里特别有意义，它不是一个凭空捏造的需求，而是真实存在、真实被重视的业务场景。
我在确定题目之前专门去翻了一些短剧小程序和数据报告，发现它们首页基本都是“猜你喜欢”“大家都在看”“新剧上新”这类信息流推荐位，播放详情页底部也会挂“喜欢这部的人也喜欢”。这些位置背后全是一套推荐算法在支撑。
1.2 用户侧、运营侧、管理侧的需求拆解
标题里写了“设计与实现”，论文里必然要过需求分析这一关。很多人写需求分析就是随便列几条，答辩一追问就露馅。我当时是老老实实把系统拆成三个视角。
用户端要解决的是“帮用户省时间”。用户需要注册登录、设置自己的题材偏好，打开首页能看到推荐信息流，点进去能看短剧详情和分集列表，播放器支持m3u8格式的连续播放，看的过程中能点赞、收藏、分享，这些行为又会反过来影响后续推荐。
运营端要解决的是“让内容流动起来”。运营人员要能维护短剧信息（封面、简介、题材标签、主演）、管理分集视频、设置推荐位和热榜权重，至少得能看见每部剧的播放量、点赞数这一类基础统计。
管理端要解决的是“权限和基础数据”。管理员管理用户状态，分配运营角色，审核上架内容。我用三张表就把这个需求串起来了，后面第4章会详细讲表结构。
1.3 这个题目的难度和工作量为什么刚刚好
毕设选题最怕两件事：太简单没东西写，太难完不成。短剧推荐系统恰好卡在中间。
对比“XX管理系统”：管理系统核心就是增删改查，没有任何算法成分，论文里只能堆页面截图，创新点无中生有。对比“电商系统”：订单、库存、支付、物流链路太长，单人开发做不完，即使做完了答辩老师也未必关心。短剧推荐系统呢，业务闭环清晰——用户进来、有了行为、系统推荐、用户再看，天然自带一个“推荐算法”的亮点。
技术栈上，前端Vue3 + 后端Node.js + MySQL都是成熟技术，2026年这个时间点各种教程、踩坑文档、组件库都非常丰富，一个人完全Hold得住。推荐算法不需要做得多高深，能把基于内容的相似度计算和UserCF协同过滤实现出来，配合一个混排公式，论文里就能写出一套完整的算法设计与实验对比，这个学术感比管理系统强太多了。
2. 选型不是拍脑袋：Node.js + Vue组合的合理性分析
2.1 为什么是Node.js而不是Spring Boot
这个问题几乎每个答辩老师都会问，所以一定要有一个站得住脚的理由。我自己当时是从三个方面论证的。
第一，单人开发效率。毕设绝大多数是一个人做，Java体系重、样板代码多，写个实体类、写个Mapper、配一套SSM框架，花在“和业务无关”的时间上太多。Node.js用Express或者Koa写接口非常快，路由即函数，中间件机制又简单，一个通用鉴权中间件几十行代码就搞定。
第二，前后端语言统一。前端Vue是JavaScript，后端Node.js也是JavaScript，类型思维和工具链完全一致。改接口参数、调数据结构、处理日期格式，前端能直接读懂后端代码，不用在Java和JS之间来回切换心智。特别是做推荐算法实验的时候，我在后端写一套相似度计算的函数，前端理清逻辑也毫不费力，这在论文写作阶段会省很多事。
第三，I/O密集型场景匹配。推荐系统最大的运行时压力不在计算，而在大量的并发读写——用户上报行为、拉取推荐列表、播放分集记录，这些都是I/O密集操作。Node.js的事件循环模型恰恰擅长这类场景。哪怕算法离线计算不依赖Node服务器实时跑，Node也完全够用。这里要诚实地说一句：如果你的推荐模块要做非常重的大规模矩阵运算，Node不是最优解，但毕设级别的数据量（几百部短剧、几千条行为记录）完全在舒适区内。
我做了一个简单的对比表，可以直接用在论文的“相关技术”章节。
| 对比维度 | Spring Boot | Node.js (Express) |
|---|---|---|
| 开发效率 | 中，样板代码较多 | 高，轻量灵活 |
| 前后端语言 | 不统一（Java / JS） | 统一（JS / JS） |
| 学习曲线 | 偏陡，依赖生态复杂 | 平缓，上手快 |
| 高并发I/O | 多线程模型，资源占用较高 | 事件循环，I/O密集场景有优势 |
| 毕业设计适用性 | 适合大型团队协作项目 | 适合单人快速交付 |
2.2 前后端分离的总体架构与数据流
整个系统采用前后端分离架构，前端Vue3 + Vite构建，负责页面渲染和用户交互；后端Express提供RESTful API，负责业务逻辑、鉴权和数据读写；MySQL存储业务数据；Nginx在部署阶段承担两个角色，一是托管前端打包后的静态文件，二是把/api开头的请求反向代理到Node服务。
数据流我建议按这条链路去理解，论文里可以画数据流图，代码里照着这个逻辑走就行了：
用户打开首页 → 前端调用GET /api/recommend/feed→ 后端拿到当前用户ID → 先从推荐缓存表取离线算好的结果 → 没有缓存就用冷启动策略（热榜+新剧+运营位） → 返回短剧列表（带推荐理由文案） → 用户点击播放 → 前端拉取/api/drama/:id/episodes拿到m3u8地址 → video.js播放分集 → 播放过程中前端自动上报行为日志 → 后端落库 → 每日凌晨定时任务重算推荐结果。
2.3 项目目录、依赖版本与开发环境清单
目录结构我直接贴我当时的工程，已经经过一次重构，比最初合理很多。前端叫short-drama-web，后端叫short-drama-server，数据脚本放db目录。
short-drama/ ├── short-drama-web/ # Vue3 前端 │ ├── src/ │ │ ├── api/ # axios请求封装 │ │ ├── views/ # 页面组件（首页/详情/播放/登录/管理后台） │ │ ├── router/ # 动态路由 │ │ ├── store/ # Pinia状态管理 │ │ ├── components/ # 短剧卡片/推荐位/播放器 │ │ └── utils/ # 工具函数 │ ├── vite.config.js │ └── package.json ├── short-drama-server/ # Node.js 后端 │ ├── routes/ # 路由：drama/user/recommend/behavior │ ├── controllers/ # 业务逻辑 │ ├── services/ # 推荐算法与定时任务 │ ├── middlewares/ # JWT鉴权等 │ ├── db/ # 数据库连接池 │ └── app.js └── db/ ├── schema.sql # 建表语句 └── seed.sql # 测试数据依赖版本方面，后端我用的是Express 4.x、mysql2（用连接池方式访问MySQL）、jsonwebtoken、bcryptjs、node-schedule。前端是Vue 3.4 + Vite 5 + Vue Router 4 + Pinia，视频播放用hls.js，因为hls.js对m3u8的处理比video.js自带的contribution-hls更灵活。建议你装nodemon做后端热更新，改完代码不用手动重启，开发体验提升一大截。
3. 推荐模块到底怎么落地：标签向量化、UserCF与混合排序
推荐系统是这篇设计的灵魂，也是论文里最能出彩的部分。但说实话，很多同学在推荐模块上容易翻车，翻车的原因不是算法看不懂，而是数据压根没设计好。所以我先从埋点讲起。
3.1 行为埋点：推荐系统做不好，八成是这一步没想清楚
没有行为数据，任何推荐算法都是空谈。你做出来的系统里如果只有注册和登录，没有用户和短剧之间的交互记录，那“推荐系统”四个字就名存实亡。
我的做法是在前端播放器组件里埋点。用户发生四类关键行为时，向POST /api/behavior/report发送一条日志：点击播放、播放时长变化（每30秒上报一次）、点赞/取消点赞、收藏/分享。后端把这批数据落进user_behavior表。行为类型我统一用字符串type字段标识，方便扩展。
// 前端播放器埋点示例（简化版） player.on('playing', () => { report({ dramaId: currentDramaId, episodeId: currentEpisodeId, type: 'play', duration: 0, }); }); player.on('timeupdate', () => { const currentTime = Math.floor(player.currentTime()); if (currentTime - lastReportTime >= 30) { report({ dramaId: currentDramaId, episodeId: currentEpisodeId, type: 'duration', duration: currentTime, }); lastReportTime = currentTime; } });离线计算时，我会把行为折算成隐式评分。这个折算规则不要太复杂，但一定要在论文里写清楚，它是你算法实验的数据基础。我当时用的权重组合是：播放完成给5分，播放时长超过50%给3分，点赞给6分，收藏给10分，分享给12分。为什么收藏比点赞分值高？因为收藏行为的成本高，用户主动“想留着之后看”，意图强度明显大于随手点赞。
3.2 基于内容的推荐：把短剧变成标签向量
基于内容推荐的核心思想是“物以类聚”。给每部短剧打上标签，把标签转成向量，计算两个向量的余弦相似度，相似度高的短剧互相推荐。
短剧的标签体系和长视频不一样，题材是第一优先级。我建了一套标签库：甜宠、虐恋、逆袭、战神、悬疑、萌宝、穿越、重生、家庭伦理、都市职场，每个短剧可以打多个标签。此外我还给每个标签手动标注了一个权重，比如一部剧的主标签权重是1.0，次要标签是0.6。这个权重可以体现在drama_tag关联表里。
余弦相似度公式不复杂，就是两个向量的点积除以模长乘积。下面是我在后端services/similarity.js里的实现，可以直接抄：
function cosineSimilarity(vecA, vecB) { const keys = new Set([...Object.keys(vecA), ...Object.keys(vecB)]); let dot = 0, normA = 0, normB = 0; for (const key of keys) { const a = vecA[key] || 0; const b = vecB[key] || 0; dot += a * b; normA += a * a; normB += b * b; } if (normA === 0 || normB === 0) return 0; return dot / (Math.sqrt(normA) * Math.sqrt(normB)); }举个例子，A剧标签向量是{甜宠: 1.0, 都市: 0.6, 职场: 0.6}，B剧是{甜宠: 1.0, 都市: 0.6, 霸总: 0.8}，C剧是{悬疑: 1.0, 推理: 0.8}。A和B都有甜宠和都市两个维度，相似度算下来会明显高于A和C。这说明B应该在A的详情页“喜欢这部的人也喜欢”里排前面。
算完所有短剧两两相似度之后，离线写入drama_similar表，用户请求详情页时直接按相似度倒序查询，不用实时计算，响应时间就是一次索引查询。
3.3 UserCF协同过滤：找到口味相同的“短剧搭子”
基于内容推荐有一个明显弱点：它只知道剧和剧像，不知道“你这个人和别人像”。所以第二路推荐我做了UserCF（基于用户的协同过滤），思路是“人以群分”。找到和你口味最像的N个用户，把他们看过而你没看过的短剧推荐给你。
UserCF分三步走。第一步，从user_behavior表里把用户对短剧的隐式评分聚合出来，形成“用户-短剧”矩阵。第二步，计算用户之间的相似度，同样可以用余弦相似度，只是把向量从“短剧标签”换成“用户对短剧的评分列表”。第三步，取TopK个相似用户，把他们评分高的短剧集合起来，按相似度加权求和得到候选剧目的得分。
// UserCF 核心逻辑（简化版） function recommendForUser(userId, topK = 10) { const matrix = buildUserDramaMatrix(); const targetUser = matrix[userId]; if (!targetUser) return []; const simUsers = []; for (const otherId in matrix) { if (otherId === userId) continue; const sim = userSimilarity(targetUser, matrix[otherId]); simUsers.push({ userId: otherId, sim }); } simUsers.sort((a, b) => b.sim - a.sim); const candidates = simUsers.slice(0, topK); // 加权聚合候选短剧 const scoreMap = {}; for (const { userId: otherId, sim } of candidates) { const watched = matrix[otherId]; for (const dramaId in watched) { if (targetUser[dramaId]) continue; // 已经看过的跳过 scoreMap[dramaId] = (scoreMap[dramaId] || 0) + sim * watched[dramaId]; } } return Object.entries(scoreMap) .sort((a, b) => b[1] - a[1]) .slice(0, 20) .map(([dramaId]) => dramaId); }这里有个实际场景要注意：用户行为矩阵非常稀疏。绝大多数用户只看过十几部短剧，而且评分维度也少。如果直接拿原始矩阵算相似度，结果容易失真，因为两个用户共同看过的剧可能很少。一个缓解办法是只统计“共同观看超过2部”的用户对，把冷门用户过滤掉，宁缺毋滥。
3.4 混合排序与冷启动兜底
两路推荐各有偏科，所以最终排给用户的列表要用一个融合公式。我用的线性加权是：
最终得分 = 0.5 * 内容相似度得分 + 0.3 * 协同过滤得分 + 0.2 * 热度得分热度得分怎么算？设计了一个带时间衰减的简单公式：hotScore = log(播放量 + 1) + 0.1 * 点赞数 + 时间衰减系数。短期热播剧会被拉起来，老剧不会霸榜。这个热力分我已经在工程里实现成一个工具函数，跑批时和推荐分一起算好存进推荐缓存表。
冷启动分两种。新用户没有任何行为数据，协同过滤用不了，内容相似也缺“种子剧”，这时候直接走兜底策略：全站热榜占60%、新剧榜占30%、运营手动配置的推荐位占10%。新剧榜非常关键，因为短剧生命周期短，用户要的就是尝鲜。运营可以在后台给指定短剧设置推荐权重，这属于“人为干预位”，在实际产品里也是标配。
混合排序之后还有一个去重规则：同一个题材连续出现两部以上就往下调一级。用户连续刷到三部霸总剧会疲劳，这个去重逻辑虽然简单，但能明显提升体验。我习惯称它为“题材打散”，论文里也可以作为一个小的优化点写进去。
4. 后端实现笔记：表结构设计、JWT鉴权与m3u8视频接口
4.1 数据库设计：六张核心表撑起整套系统
后端能撑起整套业务逻辑，数据库设计是地基。我最终落地的核心表一共六张，名字和用途如下：
| 表名 | 用途 | 关键字段 |
|---|---|---|
user | 用户账号与角色 | id, username, password_hash, role, avatar, created_at |
drama | 短剧元信息 | id, title, cover, description, status, score, total_episodes |
episode | 分集信息 | id, drama_id, episode_no, title, video_url, duration |
tag | 标签字典 | id, name, category |
drama_tag | 短剧与标签多对多关联 | drama_id, tag_id, weight |
user_behavior | 用户行为日志 | id, user_id, drama_id, episode_id, type, duration, created_at |
另外还有两张辅助表：drama_similar存离线算好的短剧相似关系，recommend_cache存用户（或匿名用户组）的推荐结果缓存。这两张表是推荐模块的“性能开关”，如果没有它们，每次请求都实时跑一遍算法，接口响应会很难看。
建表的时候我踩了一个小坑，分享给你们。user表在MySQL里是关键字，虽然加反引号也能建，但后面写SQL时到处都要加反引号，非常烦。我直接改用sys_user命名，省了一堆麻烦。短剧的video_url字段要注意字符集，m3u8地址可能带长查询参数，我用的是varchar(500)，如果是腾讯云或阿里云的私有签名URL会更长，建议直接上TEXT类型，提前避免字段溢出。
4.2 JWT鉴权与接口中间件
后端所有需要登录态的接口都走JWT鉴权。登录成功时，后端用jsonwebtoken签发一个有效期7天的token，返回给前端。前端把token存在localStorage里，每次axios请求带上Authorization: Bearer <token>。
中间件我单独抽了一个文件，任何需要鉴权的路由挂上它就行：
const jwt = require('jsonwebtoken'); module.exports = function authMiddleware(req, res, next) { const header = req.headers.authorization || ''; const token = header.replace('Bearer ', ''); if (!token) return res.status(401).json({ code: 401, msg: '未登录' }); try { req.user = jwt.verify(token, process.env.JWT_SECRET); next(); } catch (err) { return res.status(401).json({ code: 401, msg: '登录已过期' }); } };管理员和运营角色的路由还要再加一层roleMiddleware，里面判断req.user.role是不是admin或operator。答辩时老师经常会问“前端隐藏按钮和后端校验哪个安全”，答案永远都是后端校验才是真安全。前端只是视觉上隐藏，后端中间件才是真正卡住越权的防线。
4.3 m3u8分集视频的存储与接口设计
短剧视频是分集的，每一集一个独立的m3u8索引文件加一堆ts分片。我在项目的media目录下按dramaId/episodeNo组织文件：
media/ └── 101/ ├── 1/index.m3u8 ├── 1/seg-1.ts ├── 1/seg-2.ts └── 2/index.m3u8m3u8怎么来的？用ffmpeg把mp4转成HLS流，一行命令就能出片。虽然毕设阶段直接放mp4也能跑，但m3u8才是真实短剧平台的标准分发格式，答辩时能讲清楚为什么要切片，是一个加分项。
ffmpeg -i episode1.mp4 -codec: copy -start_number 0 -hls_time 10 -hls_list_size 0 -f hls index.m3u8后端接口按短剧ID返回分集列表，播放器按顺序播放。这个接口我建议挂上鉴权，防止被人直接遍历拉走整部剧。如果你想要防盗链的细节，还可以给m3u8地址加一个带过期时间的签名参数，Nginx用secure_link模块校验。毕设阶段做不做都行，但论文里提到“防盗链设计”会显得系统考虑得更周全。
4.4 离线推荐任务的定时调度
推荐结果不能每次都现算，否则并发一上来服务就废了。我用node-schedule做了一个每日凌晨3点的离线任务。
const schedule = require('node-schedule'); schedule.scheduleJob('0 3 * * *', async () => { console.log('[推荐任务] 开始计算'); await computeDramaSimilarity(); // 1. 重算短剧-短剧相似度 await computeUserCF(); // 2. 重算用户协同过滤 await refreshHotScore(); // 3. 刷新热度分 await cacheAllRecommendations(); // 4. 写回recommend_cache console.log('[推荐任务] 执行完成'); });选题的时候你可能会想：既然每天才跑一次，为什么不在用户请求的时候同步算？因为短剧的内容量虽然在增长，但和电商那种海量商品不能比，几百部短剧的两两相似度算一次只要几秒，完全没必要让在线服务扛这个计算量。离线跑批还有一个好处：可以在跑批日志里输出统计指标，比如候选集平均覆盖率、推荐列表的题材分布，这些数据后期写进论文测试章节就是现成的图表素材。
5. 前端实现笔记：动态路由、m3u8播放器与推荐信息流
5.1 动态路由：不同角色看到不同的页面
前端不是把所有人的页面都写死，而是登录后根据角色动态注册路由。我的router/index.js里定义了一个基础路由（登录页、注册页），登录接口返回role字段后，前端判断是普通用户还是管理员，再通过router.addRoute挂载对应模块。
const adminRoutes = [ { path: '/admin', component: Layout, children: [ { path: 'drama', component: () => import('@/views/admin/DramaManage.vue') }, { path: 'episode', component: () => import('@/views/admin/EpisodeManage.vue') }, { path: 'tag', component: () => import('@/views/admin/TagManage.vue') }, // ... ], }, ]; adminRoutes.forEach(route => router.addRoute(route));路由守卫里判断是否登录、角色是否匹配，没有权限直接重定向到首页。这里有一个很多新手会犯的错误：光在路由守卫里判断还不够，如果管理员退出登录换成普通用户登录，动态添加过的路由不会自动移除。我在退出登录方法里把所有动态路由名收集起来，逐个router.removeRoute()清除，再跳转登录页。这个问题你可以在答辩时主动提出来，说明你真的处理过用户态切换的边界情况。
5.2 Vue里接入m3u8播放器的正确姿势
网上搜“vue播放m3u8”会看到一大堆教程，有些让你装video.js加videojs-contrib-hls，有些让你装hls.js。我实际测试下来，hls.js在Chrome桌面端和移动端WebView的兼容性更好，包体积也更小，所以推荐直接用hls.js。
核心代码如下，逻辑非常直接：先检查Hls.isSupported()，支持就用hls.js加载m3u8地址，挂到video元素上；不支持（一般是老iOS Safari）就降级为原生播放，因为iOS原生支持Apple HTTP Live Streaming。
import Hls from 'hls.js'; function playM3u8(videoElement, url) { if (Hls.isSupported()) { const hls = new Hls({ enableWorker: true, maxBufferLength: 30 }); hls.loadSource(url); hls.attachMedia(videoElement); hls.on(Hls.Events.MANIFEST_PARSED, () => { videoElement.play(); }); } else if (videoElement.canPlayType('application/vnd.apple.mpegurl')) { videoElement.src = url; videoElement.play(); } }开发时有一个大坑我必须强调：本地起前端项目（默认5173端口），访问后端静态视频目录（默认3000端口或Nginx映射路径），很容易因为跨域导致m3u8加载失败。浏览器网络面板里m3u8请求状态是200，但ts分片全部报CORS错误。解决办法是在后端开发阶段给/media/路径加上允许跨域的响应头，生产环境由Nginx统一控制。我因为这个问题排查了整整一个晚上，一度以为hls.js配置错了。
播放器的交互层面我还加了几个细节：进入播放页自动全屏、竖屏短剧锁定竖屏比例、播放结束后自动加载下一集。自动连播和推荐系统是配套的——你看完一集，后端根据你当前的观看行为实时更新偏好向量，下一集的推荐位才会精准。
5.3 推荐信息流的组件设计与懒加载
首页信息流是整个前端最核心的页面。我拆了三个组件：DramaCard.vue负责单条短剧卡片展示，RecommendFeed.vue负责列表聚合和分页，RecommendReason.vue负责展示推荐理由标签。
这里的推荐理由不是随便写的，而是后端在推荐结果里带上reason_type字段，前端映射成不同的文案。看到“因为你看过《xxx》”的标签，说明这条来自内容相似推荐；看到“和你口味相似的人也在看”的标签，说明来自UserCF；看到“全网热播”就是热度推荐。这个设计在产品层面很实用，它让用户觉得推荐结果有解释，不是黑盒；写在论文里也很有说服力，推荐可解释性本来就是推荐系统研究的一个关注点。
列表的懒加载我用的是IntersectionObserver，滚动到底部附近时加载下一页。每次请求带上page和pageSize，后端从recommend_cache分页取数据。分页这里有个细节：不要在后端返回数据后再随机打乱，而是后端一次性返回排序好的列表，前端只负责按游标递增取片段。这样能保证用户两次下拉刷新之间的顺序稳定，不会出现重复剧集。
6. 环境配置与部署排坑：npm.ps1报错、镜像源和Nginx反向代理
6.1 Node.js和Vue环境配置里最容易卡住的三个点
先说Node.js安装。官网下载LTS版本（偶数版本），不要图新鲜装Current版。装完之后验证环境变量有没有生效，PowerShell里输node -v和npm -v，如果都能打印版本号，说明安装成功。如果提示node不是内部命令，90%是因为安装时没有勾选“Add to PATH”，要么重装，要么手动把Node安装目录加进系统环境变量Path。
第二个容易卡的点是npm官方源在国内下载慢。Vue项目跑npm install卡在reify半天不动，基本都是网络问题。解决方案是切到国内镜像源，我常用的是npmmirror。
npm config set registry https://registry.npmmirror.com npm config get registry切完之后再npm install，速度体感提升非常明显。如果个别包在镜像源上版本滞后，还可以单独指定某个包的安装源，但毕设项目很少遇到这种情况。
第三个点，Vite项目启动时版本不兼容。如果你按网上的旧教程装了Vite 2，然后用了Vue 3.5的新语法，大概率会报各种奇怪的依赖错误。我的建议是初始项目直接按官方指引创建：
npm create vue@latest它会自动帮你配好Vite、Vue Router、Pinia的兼容版本，比自己手动拼靠谱得多。需要扩展Element Plus之类的UI库时，再按需安装就行。
6.2 npm.ps1执行策略报错与国内镜像源
“npm : 无法加载文件 C:\Program Files\nodejs\npm.ps1，因为在此系统上禁止运行脚本”——这个报错在Windows上出现率极高，因为PowerShell默认的执行策略是Restricted，不允许运行脚本文件。而npm的shell脚本正是以.ps1结尾的。
解决方法两种：一是用管理员身份打开PowerShell，执行
Set-ExecutionPolicy RemoteSigned -Scope CurrentUser然后输入Y确认。RemoteSigned的意思是本机脚本可以运行，从网上下载的脚本必须有数字签名。二是不想动执行策略的话，直接用cmd命令行代替PowerShell操作npm，也能绕开这个问题。
这里多说一句：这个报错本身没有任何危险性，不要被网上一些“你要中毒了”的言论吓到，纯粹是Windows的脚本安全策略和npm安装方式之间的矛盾。搞清楚原理之后，后面遇到类似的“PowerShell禁止运行脚本”问题就都能举一反三了。
6.3 Nginx反向代理：隐藏端口、解决跨域、托管前端
本地开发的时候前端5173、后端5000，两个端口联调没毛病，但最后部署上线必须统一收敛到80或443端口。Nginx在这里同时解决三个问题：托管前端构建产物、反向代理后端API、规避跨域。
前端构建很简单，在项目根目录执行npm run build，产出dist目录，上传到服务器指定目录，然后在Nginx配置里指过去。我贴一份我当时用的精简配置：
server { listen 80; server_name your-domain.com; root /var/www/short-drama/dist; index index.html; # Vue Router history模式必须配置，否则刷新页面404 location / { try_files $uri $uri/ /index.html; } # 后端API统一走/api前缀 location /api/ { proxy_pass http://127.0.0.1:5000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } # 视频分片目录，加跨域头 location /media/ { alias /var/www/media/; add_header Access-Control-Allow-Origin *; expires 7d; } }location /里的try_files是Vue history路由的保命配置，没有它，用户刷新/detail/101页面会直接404。proxy_pass http://127.0.0.1:5000这行就是把所有/api/请求转发给Node服务，相当于把后端端口藏起来，外部只能看到80端口。用户问的“nodejs怎样隐藏post和端口号”，在生产环境的标准答案就是交给Nginx反向代理。
6.4 部署上线时容易忽略的细节
部署阶段我总结了几条容易翻车的细节，写在这里给大家省时间。
进程守护必须做。直接在服务器上node app.js运行后端，一旦进程崩了或服务器重启，服务就没了。我用的是pm2，启动命令就一句：
pm2 start app.js --name short-drama-api pm2 savepm2会自动拉起崩溃的进程，pm2 logs可以实时看输出日志，排查接口报错很方便。
数据库连接池要配置好。我用的mysql2/promise创建连接池，初始5个、最大20个连接。如果服务器上MySQL不设置连接池，推荐跑批和用户请求高峰期会把数据库连接打满。连接池代码也很短：
const mysql = require('mysql2/promise'); const pool = mysql.createPool({ host: process.env.DB_HOST, user: process.env.DB_USER, password: process.env.DB_PASSWORD, database: process.env.DB_NAME, waitForConnections: true, connectionLimit: 20, queueLimit: 0, });环境变量不要硬编码。数据库密码、JWT密钥、云存储Key这些敏感信息，我用.env文件管理，.env文件不提交到Git仓库，服务器上单独创建一份。答辩时现场演示，老师如果问“你的数据库密码怎么不加密”，你把自己的.env处理方式讲清楚，比一句“写死的”有说服力得多。
前端项目的交接也要注意。同学之间要源码，最忌讳把node_modules文件夹打包发过去，几千个小文件压缩慢、传输慢、还容易损坏。正确做法是把package.json和package-lock.json一起发过去，对方执行npm install就能还原依赖。用Git管理项目时，.gitignore里一定要写上node_modules和dist，这是我见过最多人犯的低级错误。
7. 论文怎么搭骨架：创新点、对比实验与答辩准备
7.1 论文的章节骨架怎么搭
标题里带了“论文”两个字，说明大家最终都要过论文这一关。我们学校当时要求论文包含选题背景、国内外研究现状、相关技术介绍、系统需求分析、系统总体设计、系统详细设计与实现、系统测试、总结展望这几章。我按照这个框架写下来，发现最关键的其实是每一章和工作量的对应关系。
第一章绪论写短剧行业背景和推荐系统的研究现状，这里注意要引用近两年的文献，推荐系统方向资料非常多，找5到8篇高质量论文做综述不难。第二章相关技术介绍，把Node.js、Vue.js、MySQL、推荐算法原理写透。第三章需求分析，从用户、运营、管理员三个角色画用例图。第四章系统设计，画总体架构图、功能模块图、数据库ER图。第五章详细设计与实现，贴核心代码，推荐算法部分要配合公式推导和实验数据。第六章系统测试，除了功能测试用例表，一定要有推荐算法效果的对比实验。第七章总结与展望。
一眼看下来，整篇论文的含金量集中在第五章和第六章。而这两章能不能写好，取决于你的推荐模块是不是真的跑起来了、有没有优化的过程。
7.2 创新点与对比实验怎么写
毕业设计论文最怕答辩老师问“你这个系统和别人比有什么不同”。推荐系统的融合策略就是你的创新点。我当时的创新点归纳成三条，每条都能落到代码和实验数据上。
第一条，基于内容相似度与UserCF的混合推荐策略。很多毕设只做一种算法，我做了两路并把结果加权融合。论文里我详细推导了余弦相似度的计算方法、权重融合公式、题材打散策略。
第二条，冷启动问题的分阶段处理。我把新用户、新剧、用户行为稀疏这几个场景分开设计策略，而不是一套算法打天下。新用户用“热榜+新剧+运营位”，老用户用“内容相似+协同过滤+热度加权”，这在实际产品中是很成熟的思路。
第三条，离线批量计算与在线查询分离的架构设计。推荐结果的相似度矩阵、用户协同过滤结果全部离线算好存表，在线接口只做查询和排序。这一点增强了系统的高并发能力，也体现了工程思维。
对比实验我做了三组。第一组，纯热门榜（只按播放量排序）。第二组，只用内容相似度推荐。第三组，混合推荐策略。我准备了500条模拟用户行为数据，用“点击率”和“推荐列表平均播放完成率”做指标。实验结果清晰表明混合推荐的点击率高于纯热榜约21%，高于纯内容推荐约9%。这个表格和柱状图放进去，论文的“实验分析”章节就有了硬货。答辩老师看到真实数据，明显会比看到你空口说“系统很好”要满意得多。
7.3 答辩前我复盘出来的高频问题
答辩环节基本是三板斧：为什么选这个题目、系统架构怎么样、推荐算法怎么实现的。我提前把能想到的问题全写进了准备文档，这里分享几个命中率最高的。
“为什么选Node.js不选Java？”答案在第二章第2.1节里已经讲过。注意回答时不要贬低Java，就说这个项目规模下Node.js效率更高、前后端语言统一、I/O密集场景匹配，理性分析即可。
“你的推荐算法和抖音的有什么区别？”这个问题很刁钻，核心要回答两点：一是算法基础上没有本质区别，大家的底座都是协同过滤和内容理解；二是工程粒度不同，短视频平台有实时的特征工程和深度学习模型，毕设级别用的是离线跑批加轻量在线排序。诚实承认规模差异，然后再强调自己的系统把小规模场景下的推荐流程完整跑通了，这在学习阶段更重要。
“如果数据量变大，你这个系统哪里会崩？”准备好这个问题的回答思路：性能瓶颈在离线任务的矩阵计算复杂度，优化方向是引入Spark或向量数据库；在线查询可以用Redis缓存替代MySQL的recommend_cache表。回答完优化方向，答辩老师通常不会再追问更深，因为你的思路已经足够证明你理解系统的边界在哪里。
最后说几句实际的体会
整条链路做下来，我最深的感受是：短剧推荐系统作为一个毕设题目，它的价值不在于用了多高深的算法，而在于它把一个完整的推荐业务闭环从头到尾撑起来了。从用户行为上报，到离线算法计算，再到前端信息流展示，每一环都真实存在，每一环出了问题都能追查能改进。这种完整感，是单纯的“增删改查管理系统”给不了的。
如果你正在做这个方向，我建议在数据准备上多花一点时间，提前把几十部短剧的封面、简介、分集视频素材整理好，这些内容决定了你做演示时系统的视觉效果。再就是推荐理由标签一定要做，它是你整个推荐系统“有没有灵魂”的最直观体现，也是论文截图里最能抓人眼球的部分。
做完这个项目之后，我自己又把内容相似度计算那块往深挖了挖，试过把标签向量替换成Word2Vec预训练词向量来扩充语义特征，效果比纯标签权重好一些。如果你答辩之后还想继续扩展，可以考虑这个方向，或者把推荐结果缓存从MySQL换成Redis，让在线查询性能再上一个台阶。但那是后话了，先把眼前的系统踏踏实实写完整，论文的数据跑出来，你就已经赢过大部分只写“管理系统”的人了。
