王少冬做毕设或项目练手，最怕的就是选题看起来高大上，真上手却发现业务场景撑不起代码量，最后东拼西凑一个“管理系统”交差。今天聊的这个项目——基于Java的短剧推荐系统，是我认为很值得参考的一个方向：它把当下很热的短剧内容、推荐算法、前后端分离开发全部串起来了，业务场景清晰，技术栈主流，做完以后无论是写进简历还是用于毕设答辩，都能讲出东西来。文章里我会把整个项目的设计思路、推荐算法细节、前后端实现以及调试排错过程一条龙拆开讲，代码会给出关键部分，适合正在做Java毕设、想系统学习前后端分离实战、或者准备转行做全栈开发的朋友。我们直接从项目怎么拆、怎么做开始。
1. 项目定位与整体设计思路
1.1 为什么选短剧推荐系统作为业务载体
先说说选题问题。Java方向的毕设，翻来覆去就那几类：XX管理系统、XX商城、XX平台，业务逻辑无非是增删改查。这些项目不是不能做，而是很难做出区分度。我推荐短剧推荐系统，核心原因有两个。
第一是业务场景和推荐算法天然契合。和传统长视频不同，短剧的特点是单集时长短、数量庞大、用户观看决策成本低。用户在短剧平台上的行为，比如点击、完播、点赞、收藏、追剧，会产生大量“隐式反馈”数据，这些数据正是推荐系统最好的输入。相比写一个普通的视频管理系统，推荐系统有算法、有数据流、有可优化的空间，能展示的技术深度完全不同。
第二是项目边界清晰，适合独立完成。短剧推荐系统的核心模块可以拆得很干净：用户模块、短剧内容模块、播放记录模块、推荐引擎模块。每个模块独立可测，前端页面也容易对应上。你不大会陷入“逻辑混乱、不知道下一步做什么”的困境，只要按模块推进，整个项目是能稳稳落地的。
1.2 技术栈选型与架构设计的取舍逻辑
选技术栈的时候，我的原则是：主流、够用、能讲清楚。所谓主流，就是招聘市场上常见的技术，方便你秋招春招时候讲；够用，就是不为了炫技引入一堆中间件；能讲清楚，是每一次答辩被问到“为什么选这个”的时候，你都能说出个所以然来。
后端我选择的是SpringBoot 2.7 + MyBatis Plus + MySQL 8.0 + Redis。SpringBoot不用多说，Java后端的事实标准，开发效率高，内置Tomcat，一键启动。MyBatis Plus比原生MyBatis省去大量XML编写，分页查询、条件构造器都是现成的，适合毕设这种需要快速出活的项目。Redis在这个项目里的定位很明确：缓存推荐结果、缓存短剧热度榜、存储用户临时行为会话，它不负责核心业务数据的持久化，但能让推荐接口的性能有肉眼可见的提升。
前端选择Vue3 + Element Plus + Axios + Vite。Vue3的Composition API配合Vite的开发体验比Vue2好一个档次，Element Plus组件库让你不用花大量时间写CSS就能把后台管理风格的前端页面搭起来。整套前端代码跑在Vite的8080端口，后端跑在SpringBoot的8080端口，通过代理解决跨域，这一套下来就是非常标准的前后端分离开发模式。
架构上，我把它设计成三个层级：表现层（前端Vue页面）、接口层（SpringBoot RESTful API）、服务层（推荐引擎、业务逻辑、数据访问）。没有做成微服务，不是没考虑过，而是这个体量下微服务纯属增加部署和调试成本。单机单体+缓存+前后端分离，已经足够你把推荐系统的完整链路跑通，也足够支撑并发量不大的真实使用场景。
1.3 数据库表结构设计：从播放行为说起
推荐系统的小心脏在数据，数据的小心脏在表结构。我这里把核心表分为两类：基础业务表和用户行为表。
基础业务表包括用户表、短剧信息表、短剧标签表、分类表。用户表字段不复杂，主键、用户名、密码（MD5加盐存储）、头像、注册时间。短剧信息表要重点设计，字段包括剧名、封面图URL、简介、总集数、导演、主演、分类ID、标签ID列表、平均评分、热度值。热度值这个字段很有用，冷启动阶段没有推荐数据时，直接按热度值倒序推荐，能兜底。
用户行为表是整个系统的核心资产，包括播放记录表和用户评分表。播放记录表字段有ID、用户ID、短剧ID、播放进度（看了第几集）、观看时长（看了多长时间）、完播标志（是否看完）、创建时间。这里面的“完播标志”和“观看时长”非常关键，它们是最真实的隐式反馈，比用户主动打的分数可信度还高。用户评分表则记录显式的评分行为，1到5分。
表之间通过外键逻辑关联（物理外键我建议不加，用代码保证一致性，MyBatis Plus用起来也更方便）。查询的时候通过用户行为表join短剧表获取推荐候选集，性能瓶颈会出现在这里，后面我会讲怎么用索引和缓存去解决。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 推荐算法核心：从协同过滤到混合推荐落地
2.1 推荐算法选型：UserCF与ItemCF的适用场景
推荐算法圈子里有两大经典流派：基于用户的协同过滤（UserCF）和基于物品的协同过滤（ItemCF），这两个算法面试常考，也最适合作为毕设推荐系统的核心算法。
UserCF的核心思想是“物以类聚，人以群分”：找到和你兴趣相似的用户，把那些用户喜欢但你没看过的短剧推荐给你。ItemCF的核心思想是“喜欢这个剧的人也会喜欢那个剧”：计算短剧之间的相似度，根据你历史上喜欢的短剧推荐相似的短剧。
短剧这个场景我实测下来，UserCF的效果比ItemCF好。原因是短剧内容更新极快，用户口味变化也快，UserCF能更敏锐地捕捉到“跟你相似的人群最近在追什么”，而ItemCF更偏向历史兴趣的延续。另外短剧的用户群体非常垂直，很多人在同一时间段追同样的爆款剧，用户之间的相似度计算很容易得到有效结果。当然，这不代表ItemCF没用，在用户冷启动阶段，没有足够行为数据时，ItemCF配合内容特征能作为一种不错的兜底策略。
2.2 相似度计算的数学原理与公式推导
协同过滤需要量化“相似”这个概念，最常用的方法就是余弦相似度。我们把每个用户的历史行为看成高维空间的一个向量，向量的每个维度是一部短剧，维度上的值是该用户对这部剧的偏好程度（比如观看时长归一化后的值）。两个用户的相似度就是这两个向量的夹角余弦值。
余弦相似度公式写出来是这样：
code复制sim(u, v) = ∑(r_ui × r_vi) / (√∑(r_ui)² × √∑(r_vi)²)
r_ui表示用户