基于Java的短剧推荐系统设计与实现：从协同过滤到前后端分离

做毕设或项目练手，最怕的就是选题看起来高大上，真上手却发现业务场景撑不起代码量，最后东拼西凑一个“管理系统”交差。今天聊的这个项目——基于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短剧表获取推荐候选集，性能瓶颈会出现在这里，后面我会讲怎么用索引和缓存去解决。

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表示用户u对短剧i的偏好值，r_vi表示用户v对短剧i的偏好值。分子是两个用户共同评过分（或共同观看过）的短剧的偏好值乘积之和，分母是两个用户的向量模长的乘积。这个值的范围在-1到1之间，越接近1表示两个用户的兴趣越相似。

这里有一个细节要说明：毕设阶段很多人直接用“共同观看过的短剧数量”作为相似度，不计算权重。这样做简单，但效果不好。你想想，A和B都看了一部超级爆款剧，这能说明他们兴趣相似吗？可能只是巧合。所以在实际实现中，我给不同的行为赋予了不同权重：完播一部剧权重为3，观看超过一半权重为2，单纯点击权重为0.5，打分行为直接取分值。这样构建出的用户偏好向量才有区分度。

2.3 生成推荐列表的完整流程与关键代码

算法流程可以拆成四个步骤，每一步都不复杂，但每一步都有讲究。

第一步是构建用户-短剧偏好矩阵。从行为记录表里查询最近30天的播放记录，按用户ID分组，计算每个用户对每部短剧的偏好值。为了减少计算量，可以只保留偏好值大于0的记录。

第二步是寻找相似用户。对于目标用户U，计算U与其他所有用户的余弦相似度，取Top N（这里取20）。计算相似度的时候有一个优化：只在共同行为记录上进行计算。如果两个用户没有共同看过的剧，相似度直接为0，不用做向量点积。

第三步是生成候选推荐集。从相似用户的观看记录中，找出目标用户没看过的短剧，作为候选集。候选集的每个短剧i的打分估算公式：

code复制Score(u, i) = ∑(sim(u, v) × r_vi)

v遍历所有与u相似的Top 20用户，r_vi是用户v对短剧i的偏好值。这个公式的本质是：把相似用户对这部剧的喜欢程度，按照他们和你的相似度加权求和。越是跟你相似的人喜欢这部剧，这部剧在你的候选列表里排名越靠前。

第四步是过滤和排序。要过滤掉三类内容：用户已经看过的剧、下架的剧、用户明确不喜欢的分类的剧。排序除了按Score降序，还要结合“综合热度指数”做一个加权，避免推荐结果全部集中在长尾冷门内容上，让推荐列表既个性化又有一定的普适性。

核心Java代码实现如下：

java复制public List<RecommendResult> recommendForUser(Long userId) {
    // 1. 获取用户偏好向量
    Map<Long, Double> userPref = preferenceService.getUserPreferenceVector(userId);
    // 2. 计算相似用户
    List<UserSimilarity> similarUsers = userSimilarityCalculator
            .calcTopNSimilarUsers(userId, userPref, 20);
    // 3. 生成候选集
    Map<Long, Double> candidateScores = new HashMap<>();
    for (UserSimilarity simUser : similarUsers) {
        List<WatchRecord> records = recordService
                .listValidRecordsByUserId(simUser.getUserId());
        for (WatchRecord record : records) {
            Long itemId = record.getDramaId();
            if (userPref.containsKey(itemId)) continue; // 过滤掉已看过的剧
            candidateScores.merge(itemId,
                    simUser.getSimilarity() * record.getPreferenceValue(),
                    Double::sum);
        }
    }
    // 4. 排序并返回TopN
    return candidateScores.entrySet().stream()
            .sorted((a, b) -> Double.compare(b.getValue(), a.getValue()))
            .limit(20)
            .map(entry -> new RecommendResult(entry.getKey(), entry.getValue()))
            .collect(Collectors.toList());
}

这段代码的逻辑主线很清晰，注释也写得直白，毕设论文里完全可以把它作为核心算法实现展示。要注意的是，列表的Top N数量不宜过小，一般取20左右，前端推荐流一页也正好展示20条，接口设计可以对上。

2.4 冷启动问题的应对策略与混合推荐策略

冷启动是推荐系统绕不开的话题。新用户没有任何行为数据，协同过滤算不出相似用户；新上架的短剧没有任何观看记录，也没办法被推荐出去。这个问题如果解决不好，答辩的时候一定会被老师拿捏。

我采用的方案是三层混合推荐策略。用户有足够行为数据时，走UserCF协同过滤推荐。用户有一定行为但没有足够数据时（比如行为记录少于10条），走内容推荐：根据用户已有的观看记录，提取短剧的标签、分类、导演、主演特征，计算特征向量，推荐内容特征最相似的短剧。用户完全没有任何行为时，直接返回平台综合热度榜——也就是播放量、完播率、评分三个指标加权排序后的结果。

内容推荐的相似度计算原理和协同过滤类似，只不过把用户向量换成了内容特征向量。我做了个简化版：把每部剧的标签集合（如古装、甜宠、复仇、逆袭）变成一个向量，如果用户看过带“甜宠”标签的剧，就提高“甜宠”这个维度在用户偏好向量中的权重，然后计算用户偏好向量和每部冷门新剧的内容向量的相似度。

三层策略落地之后，能把冷启动造成的“推荐空白”压缩到很低的概率。我在项目里做了一个开关，方便在后台配置每个策略的最低行为阈值，方便表演示的时候调整参数。

3. 前后端分离架构与关键模块的工程化实现

3.1 后端工程结构设计与推荐接口定义

后端工程我按标准的分层架构来组织：Controller、Service、Mapper、Entity、DTO。推荐引擎单独拎出一个recommend包，放算法核心代码，包括UserSimilarityCalculator、ContentBasedRecommender、HybridRecommender等类。这样分层的好处是，如果你后面想替换算法实现，比如改成基于深度学习的推荐，只需要改recommend包内部，做接口适配就行。

接口设计遵循RESTful风格，核心接口有这么几个：

code复制GET /api/recommend/home?size=20&page=1
GET /api/recommend/similar/{dramaId}?size=10
GET /api/drama/detail/{dramaId}
POST /api/user/register
POST /api/user/login
POST /api/watch/record
GET /api/drama/category/{categoryId}

首页推荐流接口返回的是推荐短剧的摘要信息列表，包括剧名、封面、标签、评分、热度值。这里要注意，不要直接在推荐接口里返回短剧的全部字段，一方面数据量大，另一方面会暴露没必要暴露的信息。我建了一个RecommendResultDTO，只包含前端渲染推荐卡片所需的字段。接口代码：

java复制@RestController
@RequestMapping("/api/recommend")
public class RecommendController {

    @Autowired
    private HybridRecommender hybridRecommender;

    @GetMapping("/home")
    public Result<List<RecommendResultDTO>> home(
            @RequestParam(defaultValue = "20") Integer size,
            @RequestParam(defaultValue = "1") Integer page) {
        Long userId = UserContext.getCurrentUserId();
        List<RecommendResultDTO> list = hybridRecommender.recommend(userId, size, page);
        return Result.success(list);
    }
}

对了，用户上下文的获取是用一个拦截器来做的，前端在登录成功后把token放在请求头里，后端拦截器解析token，把userId存到ThreadLocal中。这样业务代码里就不用到处传userId了，代码会清爽很多。

3.2 Redis缓存设计：让推荐接口从慢到快

推荐接口的计算过程涉及到相似度计算、候选集生成、排序，这些操作如果每次都实时算一遍，数据库扛不住，响应时间也会很慢。我第一次实测，首页推荐接口在没有缓存的情况下平均耗时480ms，qps稍微上来一点数据库连接池就报警。加缓存之后，平均耗时降到30ms以内，体感上是天壤之别。

缓存策略是这样设计的：每个用户的个性化推荐结果缓存在Redis里，key的格式是recommend:user:{userId}:{page}，value是JSON序列化后的推荐结果列表，过期时间设置为30分钟。为什么设30分钟？太短了起不到缓存作用，太长了推荐结果不新鲜，用户追完一部剧后续推荐还是旧的。30分钟是一个平衡值。

同时我维护了一个热播榜缓存，key是rank:hot，每10分钟刷新一次。这里是基于用户新行为会触发推荐结果更新这个思路，常用的写操作实时更新、读操作走缓存的模式。

有两个细节值得注意。第一，缓存更新时机：用户在观看短剧、点赞、收藏之后，我不直接清空该用户的推荐缓存，而是设置一个消息通知机制，延迟几秒后异步清理。这样防止刚看完一部剧就立刻刷新页面导致推荐毫无变化。第二，缓存穿透问题：如果用户确实没有推荐结果（极端情况），我会在Redis里缓存一个空列表结构，过期时间设短一些，比如5分钟，避免每次请求都打到数据库上。

3.3 前端Vue3页面拆解与Axios接口封装

前端页面我拆成六个视图组件：首页推荐流、短剧详情页、分类浏览页、我的播放历史、我的评分、登录注册页。其中首页推荐流是核心页面，采用瀑布流布局，上滑加载更多。

用Vue3的Composition API来组织推荐流逻辑：

javascript复制<script setup>
import { ref, onMounted } from 'vue'
import { getHomeRecommend } from '@/api/recommend'
import DramaCard from '@/components/DramaCard.vue'

const dramaList = ref([])
const loading = ref(false)
const page = ref(1)
const finished = ref(false)

const loadMore = async () => {
  if (loading.value || finished.value) return
  loading.value = true
  try {
    const res = await getHomeRecommend({ page: page.value, size: 20 })
    if (res.data.list.length === 0) {
      finished.value = true
    } else {
      dramaList.value.push(...res.data.list)
      page.value++
    }
  } finally {
    loading.value = false
  }
}

onMounted(loadMore)
</script>

这个代码包含了触底加载全部逻辑：上滑到页面底部时触发loadMore，向后台请求下一页数据，追加到数组中。React框架里类似的hooks思路一样，可迁移性很强。

Axios封装上，我统一创建了一个实例，设置了baseURL和超时时间，请求拦截器里添加token，响应拦截器里统一处理错误码。这样所有页面里的API调用都走同一套逻辑，不会出现某个页面忘记带token导致401的情况。还有一个很重要的小坑，后端返回的Long类型ID在前端JS里会丢精度，因为Java的Long是64位，而JS的Number精度有限。解决办法是让后端把ID字段序列化为字符串，我用了Jackson的ToStringSerializer来处理所有Long类型，从根上解决这个问题。

3.4 前后端联调实战：从跨域到接口文档

前后端分离项目联调的过程，本质上就是一场和前端的对齐游戏。最容易踩的坑就是跨域。我在后端配置了全局跨域处理器，放行了所有来源的请求：

java复制@Configuration
public class CorsConfig implements WebMvcConfigurer {
    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/**")
                .allowedOriginPatterns("*")
                .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS")
                .allowedHeaders("*")
                .allowCredentials(true)
                .maxAge(3600);
    }
}

注意allowedOriginPatterns不能写成allowedOrigins("")，因为allowCredentials(true)的情况下，allowedOrigins("")在很多浏览器版本会被拒绝。这是我踩过才记住的。

接口文档我用了Knife4j（SpringDoc增强版），启动项目以后访问/doc.html就能看到所有接口的请求参数和响应结构。前端联调之前，先让后端把接口文档跑起来，前端对着文档先mock数据，后端的接口开发完成后再切换成真实调用。这样做的好处是前后端可以并行开发，互不阻塞。接口字段变更时，直接改文档，前后端都在同一个文档上看最新的变更，能减少很多没必要的沟通成本。

联调过程中的字段命名也是一个高频坑。Java后端的命名习惯是驼峰命名（createTime），前端JS也习惯用驼峰，我全程都用统一命名，就不额外做字段转换了。如果你要用下划线命名（create_time），记得在Jackson配置里开启驼峰自动映射，不然前端拿到的字段全是下划线，非常别扭。

4. 调试排错实战：推荐结果、性能与常见Bug排查

4.1 推荐结果不准确的三大原因与调整策略

联调完成后，我开始自测推荐效果，发现推荐结果“不太聪明”。排查后定位到三个核心原因，这里分享出来帮大家少走弯路。

第一个原因是行为权重设置不合理。最初我给点击、播放、完播的权重分别设置为0.5、1、2，结果推荐出来的剧大量集中在“用户不小心点开就退出”的剧上。原因在于点击行为数量太大，完播行为虽然权重高但数量稀少，加权结果被点击行为主导了。调整后，我把完播权重提到5，播放时长超过一半的权重提到3，点击权重降到0.1左右，推荐质量立竿见影地提升了。

第二个原因是相似用户数量N设置太大。最初我取Top 50个相似用户，结果候选集非常大，从几十部到上百部都有，排在后面的全是一些相似度很低、只是勉强沾边的用户贡献的剧，拉低了整体推荐质量。把N调整到20以后，候选集更精炼，推荐准确率明显上升。

第三个原因是过滤逻辑有漏洞。最初只过滤了“用户完整看过的剧”，没有过滤“用户看到一半就放弃的剧”——后来发现这类剧反而不是没兴趣，也可能是因为不喜欢。我还加了一个“30天内看过但不完播的剧直接过滤”的规则，推荐列表的点击率更高了。

这些调整本质上都是在说一句话：推荐系统的效果不是算法公式写对就行，需要根据用户反馈不断调参。毕设里把这个调参过程写进结论，是一个很好的加分项。

4.2 接口响应耗时过高与数据库查询优化

在性能调优环节，我碰到的最典型问题是推荐接口偶发慢查询，最长的一次耗时1.8秒。通过打开慢SQL日志排查，定位到瓶颈在用户行为列表的查询上，它会关联短剧表查询全部字段，而且没有命中索引。

优化分三步走。第一步，给行为记录表加了联合索引idx_user_time(user_id, create_time)，因为按用户ID和时间范围查询是最主要的查询模式。第二步，把“关联短剧表查详细信息”这条SQL改成先只查ID列表，再按ID批量查短剧信息，避免大表join。在MyBatis Plus中，我用了foreach批量查询，配合IN语句一次性查出所有短剧详情。第三步，把“热播榜”“分类榜”这类冷启动兜底接口的数据缓存到Redis，让数据库的压力主要集中在用户行为写入和实时个性化查询上。

优化之后，我在本地做了简单压测：模拟100个用户、每个用户有50条观看记录的数据量下，推荐接口的P95耗时从原来的460ms降到了42ms，效果显著。同学们如果时间充裕，用Jmeter做个简单的并发测试，把测试截图放进论文里，说服力会强很多。

4.3 前后端联调的经典Bug定位思路与复盘

前后端联调期间，我整理了三个反复有人踩的经典Bug，这里逐一分析。

第一个是跨域预检请求失败。前端调用带自定义请求头（比如Authorization）的接口时，浏览器会先发一个OPTIONS预检请求。如果后端没有正确处理OPTIONS请求，前端会收到的CORS错误。解决方法除了前面说的全局跨域配置，还要确保Spring Security（如果引入了）对OPTIONS请求放行，不然预检请求会被安全拦截器拦截。

第二个是token失效但前端没有统一处理。后端返回401之后，前端页面直接白屏，没有任何提示。我在Axios的响应拦截器里加了一个统一逻辑：遇到401就清空本地token，跳转回登录页，并且提示“登录状态已过期”。这样用户不用自己去刷新页面找问题。

第三个是分页参数类型不匹配。前端传的page是字符串型（因为URL参数都是字符串），后端用Integer接收，SpringMVC会自动转换，一般没问题。但如果前端传了page=1.5这种非法值，后端直接500了，而且错误信息不够友好。解决办法是在后端加一个全局异常处理器，统一捕获参数绑定异常，返回格式化的错误信息。这个全局异常处理器在答辩演示的时候也很加分，展示了你面对异常情况的代码能力。

4.4 推荐系统自测方法：离线指标与在线体验

做推荐系统，光靠“猜”是不行的，需要有自测手段。我用的方法比较简单但有效，分为离线指标评估和在线体验验证两部分。

离线评估方面，我把用户行为数据按时间分成训练集和测试集，训练集占80%（前24天行为），测试集占20%（后6天行为）。用推荐算法基于训练集计算推荐列表，然后检查测试集中用户真正观看了多少部被推荐的剧，计算命中率和覆盖率。分配数据的时候要注意，不能按用户分组切分数据，要按时间轴切，因为协同过滤依赖于用户群体的历史行为，按用户分组切分会污染训练数据。

在线体验验证方面，我会用两个不同账号分别观看不同类型的短剧（一个主看古装甜宠，一个主看都市逆袭），然后回到首页观察推荐列表是否出现了明显的差异化。这个验证方法非常直观，也是答辩现场最容易演示的效果之一。建议所有做推荐系统毕设的同学都提前准备两个账号的数据，避免现场演示时推荐结果“不够个性化”，老师会觉得算法是摆设。

5. 项目打包部署与加分项设计

5.1 本地打包与部署实操要点

项目做完之后，还需要能跑起来给别人看，万无一失的部署很重要。前端是Vite工程，打包命令很简单：

bash复制npm run build

打出来的静态文件放在dist目录下。后端是SpringBoot工程，Maven打包生成jar包：

bash复制mvn clean package -DskipTests

这里有个常见坑：后端打包时如果引入了某些依赖的特定版本，可能会导致打包后的jar在无网环境下启动报错，比如很多聚合工程把公共模块做成本地模块依赖，而本地模块没有install到本地仓库。解决方法是先执行mvn install把公共模块装进本地仓库，再执行package。

我最终部署的时候选了最省心的一招：前端构建后的dist目录里的静态文件，直接复制到SpringBoot的src/main/resources/static目录下，一并打成jar包。这样启动一个SpringBoot进程就能同时访问前端页面和后端接口，完全没有跨域问题，部署成本最低。虽然严格意义上这是“前后端一体部署”了，但在毕设演示和本机跑通的场景下最不容易出意外。我也单独保留了前后端分离的部署方案（前端配Nginx反向代理后端接口），两种都在文档里写明做法。

5.2 论文和答辩中共识的加分配置项

如果想让这个项目的档次再往上走一步，我建议补上下面三个设计点，它们不会增加太多编码量，但答辩时讲出来非常有价值。

第一个是引入RabbitMQ做异步消息解耦。用户观看行为不直接同步写入数据库，而是发送一条消息到RabbitMQ，由消费者异步落库并触发推荐缓存的更新。这样做的理由很好讲：高并发下避免数据库写压力过大，也避免用户观看接口因为同步处理推荐更新而响应变慢。

第二个是给系统增加一个简单的管理员后台。管理员可以维护短剧信息、上下架短剧、查看推荐系统的点击率数据。这一步把系统从一个纯用户端产品变成了“有管理视角的完整平台”，完整度上一个层次。

第三个是做一个推荐效果看板。统计每位推荐位的曝光量、点击量、点击率，按小时维度展示曲线，用来评估推荐算法的好坏。这个看板的数据源可以从用户行为表和曝光记录表聚合出来，工作量不大，但在论文里几乎可以作为“推荐系统评估与验证”这一章的支撑材料。

这些加分的核心逻辑是：让老师看到你对“推荐系统”这个主题的理解不止于一个算法Demo，而是有工程完整性、有评估意识、有架构思想。

6. 从毕设到项目经验：这套体系还能怎么扩展

如果你打算把毕设项目进一步包装成简历上的亮点，有几个扩展方向很值得尝试。

第一个是把推荐算法从“离线计算”升级成“实时流式计算”。当前实现是学习完历史行为后计算推荐的逻辑，适合活动推广场景。但结合Redis存储实时行为，再用定时任务每5分钟增量更新一次推荐结果，就可以把它包装成“准实时个性化推荐”，听起来就比纯离线的高一个档次。

第二个是在前端加一个“推荐理由”模块。推荐列表里每张短剧卡下面显示一行小字：“因为你看过《XX》，推荐你这部《YY》”，或者“和你品味相似的观众都在追这部剧”。这个功能实现起来难度不高，只需要把推荐算法里的候选集生成过程记录下来，把关联来源暴露给前端。但它的作用是巨大的，它把“黑盒推荐”变成“可解释推荐”，无论是产品体验还是论文的理论价值，都能明显提升。

第三个是收集更多维度的用户行为。比如搜索行为、收藏短剧后取消的时间、分享行为。每多一类行为数据，推荐算法的输入就多一个维度，推荐效果就多一分提升空间，这个扩展点同样可以在论文里大书特书。

我个人在实际操作中的体会是，做这种全栈加算法的毕设项目，最大的收获不是代码量写了多少，而是建立了一套完整的“发现问题—定位问题—解决问题—评估效果”的闭环方法论。短剧推荐系统这个选题特别适合作为这套方法论的载体，它不算太难，但每一环都有真问题可以挖，做完之后你会对前端的交互逻辑、后端的接口设计、数据库的查询优化、推荐算法的落地实现都有具体的体感，而不是纸上谈兵。

最后再分享一个小技巧：项目里一定要多写日志。我在推荐引擎的关键节点都加了log.info和log.warn输出，比如“用户[123]计算相似用户耗时45ms，命中相似用户18人”。调试的时候这些日志是你定位问题的最好线索，答辩的时候如果你能现场演示“通过日志定位了一个性能瓶颈的过程”，那个说服力比任何PPT都强。如果时间允许，把日志组件切换成Logback并配置按天滚动，完整记录项目运行期间的日志，对后续排错和论文写作都有帮助。