Spring Boot+大数据电影推荐系统毕设：从源码吃透到答辩通关

每年毕设季都能看到很多和电影推荐系统相关的题目，Spring Boot + 大数据技术的组合更是高频出现。我帮人调试过几个同类项目，自己也完整搭过一个用于演示的模拟项目X。说句实话：这个题不难，但很烦。不难，是因为公开案例多，很多模块都有现成方案；很烦，是因为做得太雷同，评委一眼就能看出你是拿了别人的源码改了改就交。这篇文章不评价买源码这件事是对是错，只讲一个非常实际的问题：当你拿到一套基于Spring Boot和大数据技术的电影推荐系统源码和文档之后，怎么把它吃透、跑通、讲明白，最后变成能在答辩现场站得住脚的东西。

如果你正在考虑要不要选这个题，也需要一条完整的技术路线，那这篇文章同样适用。我会尽量按做项目的顺序来拆：先看这个选题在毕设里到底占什么分量，再讲技术选型，然后是推荐引擎的核心链路、功能模块、常见坑和答辩准备。文里的代码片段都是演示级的，你要理解的是思路，不是复制粘贴。

1. 先想清楚：电影推荐系统这个毕设题，到底在考你什么

1.1 为什么这个题看起来简单，但答辩容易翻车

电影推荐系统大概是推荐系统方向里最容易入手的题目。原因很简单：需求足够直观，用户看了一堆电影，系统给用户推荐没看过的电影，谁都能理解；素材也容易找，公开的电影信息、评分数据一大堆；算法理论也成熟，协同过滤、矩阵分解、物品相似度这些概念在教材里反复出现。所以很多同学选题的时候，几乎不用花什么力气就能让导师点头。

但到了答辩现场，翻车的也特别多。最常见的场景是：演示页面很流畅，一打开就有“猜你喜欢”，但评委随口问一句“你这个推荐结果是怎么算出来的”，学生就开始背概念。背完“协同过滤分两种，基于用户和基于物品”，评委再问“你自己代码里用的是哪一种？特征向量存在哪儿？模型多久训练一次？新用户怎么办？”——这一串问题下来，基本就卡住了。

问题的根源不是算法太难，而是大多数人在做项目的时候只关心“跑起来”，没关心“数据怎么流动”。推荐系统和普通管理系统最大的区别在于，它是一个有计算链路的数据系统，而不是几个增删改查页面。你不仅要告诉评委“我做了一个推荐”，还要告诉他“用户的行为数据从哪个表来，经过什么算法，最后通过什么接口返回”。这整条链路，才是这门课真正想考察的东西。

1.2 推荐系统的完整技术链路拆解

把这条链路拆开，大致是下面几步：

1. 用户在前端点电影、看详情、收藏、评分，前端把行为通过接口提交到后端。
2. 后端把行为记录到行为日志表和评分表。
3. 离线任务读取历史行为数据，做清洗和转换，形成训练集。
4. 用协同过滤算法训练模型，或者用相似度计算生成候选集。
5. 对每个用户生成Top-N推荐列表，过滤掉已经看过的电影，再按规则排序。
6. 推荐结果存入Redis缓存，Web接口直接读缓存返回。
7. 前端拿到结果，渲染成“猜你喜欢”“热门电影”等栏目。
8. 用户对推荐结果产生了新的点击或评分，又回到第一步。

这条链路看起来简单，但每一步都有隐藏工作。比如第一步涉及到日志怎么埋；第二步涉及到数据表怎么设计；第三步涉及用Spark还是用自写算法；第四步涉及ALS参数；第五步涉及过滤规则；第六步涉及缓存失效策略；第七步涉及接口幂等；第八步涉及如何评估推荐效果。一个完整的毕业设计，不需要每一步都做得很深，但每一步都得有得说。

我在帮A同学调试的时候发现，他拿到的源码里其实把前面几步都写了，但他根本不知道哪些代码对应哪一步。他把所有配置文件、Controller、Service、工具类一股脑全打开，越看越乱。后来我让他从一条数据的主线去读：注册一个用户，给一部电影打5分，然后查数据库里多了一条什么记录，再触发训练，看Redis里有没有生成推荐结果。主线走通之后，整个项目一下子就清晰了。

1.3 和电商推荐相比，电影场景的特殊性

很多教材讲推荐系统喜欢拿电商举例，但电影和电商在推荐场景上差别很大，这个差别直接决定了你的算法选型和数据设计。

因为电影评分严重稀疏，直接用最朴素的“基于物品的协同过滤”在计算相似度时很容易遇到两个电影共同被评分用户很少的情况。所以在实际项目中，很多人会选择ALS矩阵分解，或者加一些内容特征做混合推荐。另一个重要点是，用户对电影的偏好有很强的时间特征：一个人大学时喜欢看文艺片，工作以后可能开始看悬疑片。如果系统只拿全量数据训练，不区分时间窗口，推荐结果就会偏“保守”。

这些细节都值得写进论文的“需求分析”部分。别小看这一节，它决定了评委对你项目的第一印象：是真的做过思考，还是仅仅把代码跑通而已。

2. 技术选型不是堆名词：Spring Boot和大数据技术怎么分工

2.1 一套不劝退的技术栈清单

很多同学看到“Spring Boot + 大数据技术”，第一反应是把能想到的技术全写上：Hadoop、Spark、Flink、Kafka、Flume、Hive、HBase……一张技术栈表格列了十几个名词，看起来很唬人，但真做起来每一样都是负担。毕业设计的时间有限，正确的做法是选一套“能跑通、能解释、能扩展”的最小组合。

我建议按下面这套来配：

这里的每一项都不是摆设。Redis之所以比MySQL更适合放推荐结果，是因为推荐列表需要被高频读取，而且内容可以接受暂时不精确。如果每次请求都从MySQL全表算一遍相似度，哪怕几千条电影数据也能把接口拖到几百毫秒。

2.2 为什么大数据组件里先选Spark，而不是凑一套全家桶

有人可能会问：既然标题里写了“大数据技术”，为什么不用Hadoop存文件、用Kafka传日志、用Flink做实时推荐？答案很简单：在小数据量下，这些组件带来的复杂度远超收益。一个毕设项目通常只有几千部电影、几十万条评分，全放在MySQL里完全没有任何压力。你强行上一个Kafka+Flink，训练完的模型文件都不知道往哪放，演示时还容易因为某个组件没启动而翻车。

更务实的选择是把“批量离线训练”这件事做好。大数据技术在这个项目里的定位，不是“数据大到必须用分布式”，而是“推荐模型的训练和推断，适合用面向批处理的算法框架来做”。Spark MLlib中的ALS就是一个非常好的落点：它接受一个评分表，训练出两个矩阵，然后可以批量生成全量用户的Top-N列表。整个过程是离线完成的，天然符合“大数据离线计算”的描述。

如果你确实想体现一些“准实时”效果，可以做热点榜单的定时统计，比如每隔10分钟用SQL或Spark作业统计最近7天的热门电影，再写回Redis。把这种“离线批量 + 在线缓存”的结构讲清楚，比堆一堆启动不起来的大数据组件强太多了。

2.3 Spring Boot在整个项目里扮演的角色

Spring Boot在这个系统里不是核心算法，而是“调度中枢”。它负责接收前端请求，做参数校验、登录鉴权、数据库读写，然后在合适的时机调用推荐引擎。

实际开发时要注意模块划分。我见过有些源码把所有代码都塞在Controller里，一个方法几百行，算法逻辑和SQL混在一起，看着就想摔电脑。一个稍微清爽点的做法是把系统拆成几个模块：

• controller：接口层，只做参数接收和结果返回
• service：业务逻辑，调用数据访问对象和推荐服务
• mapper/repository：数据库操作
• recommend：推荐引擎模块，包含ALS训练、结果过滤、Redis读写
• common：统一返回体、异常处理、工具类

Spring Boot的优势在于这些模块能快速被组合起来。尤其推荐引擎这部分，最好设计成一个独立接口，例如RecommendService，底层不用关心是Spark训练还是纯SQL算出来的。这样答辩的时候你还能说：“推荐算法和业务模块解耦，以后可以平滑替换成其他算法模型。”这句话很多评委爱听。

2.4 数据规模不够，怎么让“大数据”名号站得住

这是电影推荐毕设最尴尬的问题：你的训练数据可能只有几千条，离“大数据”差得很远。怎么处理？我建议从两个角度去讲。

第一，强调“面向大数据场景的设计”，而不是“当前处理的数据量”。比如MySQL中的评分表可以按用户ID分片，训练任务可以提交到Spark集群而不是本地模式，推荐结果可以通过Redis集群做分布式缓存。这些设计在数据量增长时不需要推翻重来。

第二，用公开的数据集扩充演示数据。网络上有很多电影评分数据集，包含数百万条匿名评分记录，都是可以下载的。你可以在本地导入一部分，生成更大的训练集，再验证明白模型训练耗时和数据量的关系。这样做还有个额外好处：论文里能有一张“不同数据量下的训练耗时对比”表，很加分。

我之前在模拟项目X里就是这么做的：先用500条数据把功能跑通，再导入10万条评分数据重新训练。结果本地单机训练也只花了不到一分钟，但已经足够说明Spark处理批量数据的能力了。拿到这种对比数据，你在答辩时的底气会完全不一样。

3. 推荐引擎的核心链路：从用户行为到“猜你喜欢”

3.1 用户行为数据怎么设计，决定了系统有没有“弹药”

推荐系统最怕的不是算法烂，而是没有有效数据。很多毕设项目把用户点击、浏览、评分混在一个日志表里，没有区分行为类型，也没有时间戳，最后训练出来的结果没有任何意义。所以数据表设计是整个项目的地基。

我的建议是至少拆成四张核心表：

• 用户表：user_id、username、password、preferred_genres（偏好类型，注册时可多选）
• 电影表：movie_id、title、genres、release_year、rating_avg、rating_count
• 评分表：user_id、movie_id、score（1-5分）、create_time
• 行为日志表：action_id、user_id、movie_id、action_type（view/favorite/play）、create_time

评分表是模型训练的主数据，行为日志表主要用于热门统计和辅助特征。很多同学图省事，把评分也放在行为日志里，然后训练时再过滤action_type='rating'，这当然也能跑，但会让SQL和Spark作业的过滤条件到处散落，增加理解成本。分开写，各管各的，后期改逻辑更方便。

埋点这块也值得注意。前端在进入电影详情页、点击收藏、提交评分时，都要主动向后端发送行为接口请求。如果用的是前后端分离项目，可以在请求拦截器里统一加一个recordBehavior的异步调用，免得每个页面都重复写。

3.2 ALS矩阵分解的通俗解释

ALS是Alternating Least Squares的缩写，也就是交替最小二乘法。要理解它，先得理解协同过滤里的矩阵分解思路。

假设系统里有M个用户、N部电影，把用户对电影的评分看成一个大矩阵，行是用户，列是电影，矩阵里很多位置都是空的，因为用户不可能给所有电影打分。矩阵分解的基本想法是：用一个低维特征来表达用户和电影。比如把所有电影归纳成5个隐藏主题，每个用户对每个主题有一个偏好值，每部电影在每个主题上的含量也有一个值，用户对某部电影的综合评分，就是这两个向量点乘的结果。

ALS的“交替”体现在求解过程中：先随机初始化用户特征矩阵，固定它，去求让损失函数最小的电影特征矩阵；然后反过来，固定电影特征矩阵，去更新用户特征矩阵。这样来回迭代，直到模型收敛。这种做法把复杂的矩阵补全问题，拆成了一串可以并行计算的最小二乘问题，所以非常适合Spark。

用Spark MLlib实现很简单，就是先读一个评分数据集，再建ALS估计器：

SparkSession spark = SparkSession.builder() .appName("MovieRecommendALS") .master("local[*]") .getOrCreate(); Dataset<Row> ratings = spark.read() .option("header", true) .csv("file:///data/ratings.csv"); ALS als = new ALS() .setMaxIter(10) .setRank(20) .setRegParam(0.1) .setUserCol("userId") .setItemCol("movieId") .setRatingCol("rating"); ALSModel model = als.fit(ratings); model.write().overwrite().save("file:///models/alsModel");

代码里的rank表示隐藏特征的维度，maxIter是最大迭代次数，regParam是正则化参数。这几个值不需要一开始就调最优，先用默认组合跑通，再慢慢调。我后面会专门说参数坑。

3.3 从训练结果到“猜你喜欢”

训练完成后，Spark的ALS模型可以直接为某个用户预测对某部电影的评分，但一次只算一个用户一个电影会很慢。常规做法是直接生成所有用户的Top-N候选列表。

在Spark里可以用model.recommendForAllUsers(10)来批量生成每个用户评分最高的10部电影。拿到结果后不要直接返回给页面，还要做两件事：

1. 过滤掉用户已经评分过的电影，不然推荐结果里出现用户已经看过并打分的电影，体验很差。
2. 做业务排序。比如相同预测分的电影，优先推近期热门，或者优先推与用户注册偏好一致的影片。

过滤后的推荐列表需要写回Redis。Redis的key可以设计为rec:user:{userId}，value直接存电影ID的JSON数组，设置过期时间，比如3小时。这样用户刷新“猜你喜欢”时，接口不用去跑模型，直接取缓存，响应时间能控制在几十毫秒以内。

这里要特别提醒：模型训练是离线的，所以每次用户新打分后，推荐结果不会立刻变化。有些同学演示时给电影打了分，然后马上刷新页面，发现推荐没变，以为系统坏了。实际上这是正常的，你需要手动触发一次重新训练，或者等待定时任务跑完。答辩前要提前做好这个预期管理。

3.4 实时热门榜到底在“实时”什么

热门榜单是另一个推荐位，实现起来比“猜你喜欢”简单得多，但却能体现系统的实时性。你说的“实时”不是模型实时更新，而是榜单数据每隔几分钟更新一次。

我常用的公式是：

热度分 = 评分次数 × 0.4 + 收藏次数 × 0.3 + 播放次数 × 0.3

如果还想加时间衰减，可以用：

热度分 = Σ(行为权重 × exp(-时间间隔 / 时间窗口))

实现时，写一个定时任务，每隔10分钟从行为日志表汇总最近7天的行为数据，计算每部电影的热度分，按分数倒序取前30名，写入Redis的hotMovies。读取接口就很简单：

@GetMapping("/api/recommend/hot") public Result hotList() { String hotKey = "hotMovies"; List<String> ids = redisTemplate.opsForList().range(hotKey, 0, 9); List<Movie> movies = movieService.listByIds(ids); return Result.success(movies); }

为什么要把热门榜单独做一层？因为如果推荐系统只有“猜你喜欢”，评委可能会质疑“你到底有没有离线计算和在线服务的配合”。有了热门榜，你就能讲出一个非常清晰的“离线算权重、在线读缓存”的架构。这个架构不一定多高级，但逻辑足够完整。

4. 除了推荐算法，这四个功能模块也必须能打

4.1 后台管理模块：证明它是一个“系统”而非一个算法脚本

很多同学做完推荐算法，就默认项目完成了一大半。但评委看的是一个“系统”，后台管理界面正好是判断项目完整度的最直观证据。后台不需要太复杂，但至少要包含：

• 电影管理：新增、编辑、删除电影信息，支持按类型和上映年份筛选。
• 用户管理：列表、锁定/解锁、查看某用户的历史评分。
• 评分数据管理：查看最新评分记录，必要时手工删除异常评分。
• 推荐结果管理：查看某个用户当前Redis中缓存了哪些推荐电影，支持手动清除缓存。

最后这个“推荐结果管理”很加分，因为你可以现场演示“清掉某用户的Redis缓存，让他重新刷新页面”，这样就能在答辩时展示推荐的离线生成和缓存回退机制。

后台页面用什么技术不是重点，重点是接口要能看到真实数据流动。我曾经看到有个项目，后台的电影管理和推荐结果完全对不上，一看就是前后端各干各的，这种细节一旦被评委发现，印象分直接掉。

4.2 用户端核心页面：入口要做扎实

用户端是整个系统的数据入口，没有用户操作，推荐系统就是无米之炊。用户端最核心的页面有四块：

1. 登录注册页：密码不能明文存，至少用MD5加盐或BCrypt加密。
2. 电影列表页：分页显示，支持按类型、年份、评分排序。
3. 电影详情页：展示基本信息、平均评分、评论列表，同时隐藏埋点调用。
4. 用户个人中心：展示浏览记录、评分记录、收藏列表。

电影详情页是行为埋点的关键位置。用户进入详情页、点击“收藏”、提交评分，每一次操作都应该在后端留下痕迹。接口大致长这样：

@PostMapping("/api/behavior") public Result record(@RequestBody BehaviorLog log) { logService.save(log); return Result.success(); }

这个接口的调用放在前端页面可能只是一个几行的JS方法，但它是整个推荐系统的“数据源”。答辩时别光顾着介绍界面好看，要着重强调“每次用户行为都会被记录，并进入后续的推荐计算”，这样才能把页面和算法绑定起来。

4.3 推荐接口层：统一入口，快速响应

推荐接口一般设计成三个就好，太多反而不好讲：

• /api/recommend/guess/{userId}：猜你喜欢，读取Redis中用户专属推荐列表。
• /api/recommend/hot：热门电影，读取Redis热门榜。
• /api/recommend/similar/{movieId}：相似电影，根据电影内容特征或实时计算生成。

其中相似电影接口可以先不依赖ALS，直接根据电影的导演、演员、类型做标签匹配，再结合评分排序。这个接口实现起来快，效果也很直观，用户在看某部电影详情页时可以看到“喜欢这部电影的人也喜欢”。

接口层要注意统一返回结构。我习惯用Result<T>包装所有接口返回，里面包含code、message和data三个字段。这样做的好处是，前端所有请求都可以共用同一个拦截器处理错误，而且Swagger文档看起来也更整洁。

4.4 可视化大屏：让评委的注意力从代码转移到故事

为什么很多推荐系统毕设都会配一个大屏？不是因为它技术难度高，而是它能把枯燥的指标变成可视化的故事。大屏一般包含几块内容：电影总数和用户总数、评分分布直方图、热门电影Top10、电影类型占比饼图、最近7天用户活跃趋势。

用ECharts做这些不需要太多代码。我从模拟项目X里抽一个很简单的例子，比如类型占比：

var chart = echarts.init(document.getElementById('genreChart')); chart.setOption({ series: [{ type: 'pie', radius: ['40%', '70%'], data: [ { value: 320, name: '剧情' }, { value: 210, name: '喜剧' }, { value: 158, name: '动作' }, { value: 120, name: '科幻' } ] }] });

关键在于这些数据要从后端统计接口实时拿，而不是写死在前端。这样做有个很好的答辩角度：你能从大屏观察到推荐系统是否在正常接收行为数据，比如用户活跃数涨了，类型占比变化了，说明系统闭环在运转。评委问“你怎么评估推荐效果”时，你也能借用大屏的数据说，“我们统计了曝光点击转化率”——当然，前提是你真的做了这个统计。

5. 踩坑复盘：训练、冷启动和演示时最容易翻车的地方

5.1 ALS参数怎么调，以及数据太稀疏怎么办

ALS模型三个最常被问的参数，我在调参时是这样理解的：

• rank：隐藏特征维度。太小表达不了用户偏好，太大容易过拟合且训练变慢。小数据集一般10到20就够，不要一上来就设50。
• iterations/maxIter：迭代次数。默认10一般够，如果发现损失还在明显下降，可以调大到15到20。
• regParam：正则化系数。数据稀疏时适当调大一点，比如0.1到0.5，可以缓解过拟合。

一个常见场景：你只有几百个用户、几千条评分，ALS训练出来的模型可能还不如“直接推热门”的规则管用。这种时候别死磕ALS，可以在论文里做对比实验：基于ALS的推荐和基于物品相似度的推荐分别跑一遍，用准确率或召回率对比。只要实验设计严谨，结论是“在小数据下规则方法更优”也没问题，因为这说明你做了真实的实验分析。

5.2 冷启动问题：没看过片的新用户怎么办

冷启动是推荐系统领域的老大难，也是评委会重点追问的点。新用户第一次登录没有任何行为记录，ALS模型给不出任何有意义的预测。我的处理方案是在注册时收集用户的电影类型偏好，也就是preferred_genres字段。这样新用户登录后，可以先推荐该类型下评分最高的电影，而不是返回空列表。

新电影冷启动则要靠在电影表中补充足够的内容信息，比如导演、演员、简介关键词。相似电影推荐可以先用内容特征算，等新电影积累了一些真实评分后，再逐步进入协同过滤候选集。这样就能在答辩时展现你对问题的思考深度，而不是只会说“我们用的是标准协同过滤”。

另外，Redis里没有缓存的情况也要兜底。接口在查询推荐列表时，如果发现对应key不存在，不要直接返回空，要回退到“热门电影 + 高分电影”的组合列表，并异步触发一次该用户的推荐结果生成。这样系统永远有内容可返回，体验不会断。

5.3 “大数据”名不副实怎么应对评委追问

评委里如果坐了一位懂大数据的老师，你千万别在答辩时把一个单机Spark程序吹成“大规模分布式系统”。正确的话术是：“项目的核心流程是从离线批量计算到在线缓存服务，当前演示环境采用本地模式验证；当数据量增长时，Spark任务和Redis缓存都可以平滑迁移到集群部署。”这句话既诚实，又给了系统扩展空间。

你还可以准备一张实验表，记录不同数据量下ALS训练耗时。如果10万条数据只需要几十秒，那已经很能说明问题了。我当时在模拟项目X里测过三组数据：5万条耗时8秒、10万条耗时15秒、50万条耗时55秒。这个数据一贴出来，评委基本不会再纠结“你算不算大数据”了，因为趋势很明确。

5.4 远程调试和演示时的四个实操坑

标题里提到的“远程调试”其实是很多拿到源码的同学最需要的服务，但归根结底还是要自己掌握基本排查手段。我在帮人远程处理问题时，最常见的就这几个：

1. 端口被占用或没启动：Spring Boot默认8080，但本机可能被其他进程占用了。演示前先用netstat -ano | findstr 8080查一下。
2. 模型文件路径不对：训练好的模型放在本地目录，换了电脑没把模型一起带过去，启动时就会报找不到模型。建议把模型的加载逻辑做成“不存在就自动训练”。
3. Redis还没启动：很多模块启动时能正常出页面，但一点推荐接口就报错，十次里有八次是Redis挂了。
4. 推荐结果没刷新：手动触发重新训练的接口没被调用，导致新评分并未生效。可以在后台加一个“重新训练”按钮，答辩前先跑一次。

演示前一定要走一遍“清缓存、重启训练任务、打开页面”的全流程。不要等到被评委看着的时候再临时操作。

6. 从“能跑”到“能答辩”：文档、演示和定制怎么准备

6.1 论文结构怎么和项目真正对应

很多同学从网上下了一套代码，里面带着一份现成的论文。但如果你不把论文改成自己理解的版本，答辩时两张皮的问题非常明显。理想情况下，论文应该和项目模块一一对应：

• 需求分析：写清楚电影推荐系统的用户角色、功能需求和非功能需求。
• 系统设计：画系统架构图、功能结构图、数据库ER图。
• 核心算法：重点写ALS矩阵分解的公式、训练流程、参数选择。最好附上损失变化图或用户推荐效果示例。
• 系统实现：按功能模块贴核心代码，不要贴大段没用的Controller。
• 系统测试：至少包含功能测试用例和推荐效果对比数据。

写论文的时候，你要能把每个章节讲到两分钟以上。如果你发现自己讲不出，说明还没吃透，需要回去看代码。

6.2 演示脚本：先走业务流程，再展示算法亮点

答辩演示控制在10分钟以内，顺序很有讲究。我建议按这条线走：

1. 登录一个普通用户账号，快速浏览首页的热门电影和猜你喜欢栏目。
2. 打开一部电影的详情页，顺便演示相似电影推荐。
3. 给某部电影打5分，刷新个人中心确认评分记录已生成。
4. 后台触发一次重新训练或等到定时任务跑完，再刷新猜你喜欢，观察结果变化。
5. 切到可视化大屏，展示用户行为统计、热门Top榜和推荐覆盖率。
6. 最后可以演示一个“新用户注册”，注册时选择偏好类型，登录后看系统给推荐了什么，引出冷启动策略。

这套流程每个环节都有目的，不像有些同学打开管理端一顿乱点。如果你时间有限，至少要把第3步到第4步的闭环讲清楚，因为那是推荐系统最核心的“行为-训练-推荐”链路。

6.3 定制和扩展：同一个骨架能变出多少种题目

“定制”也是这个项目常见的服务点。很多人问我：“能不能帮我把电影推荐改成课程推荐？”其实可以，而且不难。因为核心链路都是一样的：用户对课程有学习行为，系统根据行为数据训练模型，再通过接口推荐。你只需要替换数据源和前端页面。

具体来说，可以做这些方向的扩展：

• 结合内容类型：比如给每部电影打标签，用标签向量相似度做内容推荐。
• 加权混合推荐：把ALS预测分和内容相似度按权重融合，设置一个可调系数。
• 实时化改造：引入消息队列接收行为日志，用Flink或Spark Streaming做增量更新。
• 前后端容器化：用Docker Compose把MySQL、Redis、Spring Boot、前端打包，一键启动。

但要提醒一句：扩展方向不要贪多。选定一个方向做到有对比、有数据，比十个方向都点一下要强得多。

6.4 从“全套源码”里学到什么，才不算白拿

手里有一份全套源码+文档，最忌讳的做法是把源码解压后直接改个系统名和数据库名就交。按我的经验，正确消化一套源码至少要过四关：

第一关是读懂“依赖地图”。打开pom.xml或build.gradle，看看项目里到底引入了哪些依赖，哪些和推荐计算有关，哪些只是辅助。再看application.yml里的数据源配置、Redis配置、是否配置了定时任务。

第二关是跑通“一条主流程”。从注册一个新用户开始，到给电影打分，再到后台查看数据、触发训练、查看推荐结果，每个环节都要能对应到代码文件。

第三关是注释和接口文档。给每个Controller方法、Service方法写一句中文注释，不是为了交差，是为了逼自己读代码。某一处读不懂就先打个断点，调试看数据。

第四关是重写自己的答辩讲解稿。不用长篇大论，但必须用自己的话把“系统分几个模块、推荐怎么算、缓存怎么用、冷启动怎么办”这四件事讲清楚。

过了这四关，源码才能真正变成你的东西。如果过不了，哪怕远程调试一百次，也只是别人把问题解决了，你依然没学会。

最后再说一句实在话：推荐系统的模型部分是锦上添花，数据链路才是基本功。你只要肯花两个星期把用户行为、离线训练、Redis缓存、接口展示这条链路从头到尾跑通一遍，答辩时基本没人能问倒你。至于那些更花哨的算法和框架，等你把基础链路吃透了，后面再慢慢玩也不迟。