基于SpringBoot的电影推荐系统设计与实现

做毕设选方向的时候，我把“基于SpringBoot的电影推荐系统”列进了候选清单，最后也真就把它做完了，整套源码加文档顺下来差不多花了一个多月。这个选题在Java方向里属于很稳的组合：SpringBoot把后端业务、权限、数据持久化全部扛起来，推荐算法负责让系统“懂用户”，前端再配一套Vue页面，从数据库设计到算法实现再到前后端联调，一整条链路走完，能覆盖的知识点非常全面，代码量也足够撑起一篇像样的毕业设计论文，而且抽到相关面试题时还能拿真实项目举例。

这套系统能做的事情很直白：用户注册登录后，可以浏览电影、按类型筛选、搜索片名，给看过的电影打分；系统会根据用户的历史评分行为，利用协同过滤算法生成“猜你喜欢”的推荐列表，还会按热门程度、最新上映等维度输出榜单；管理员则可以在后台管理电影信息、分类标签、用户状态，看基础的数据统计。它解决的并不是“怎么搭一个CRUD系统”这种入门问题，而是把业务系统和算法引擎揉在一起，做一个真正有“智能感”的完整应用，适合用来做毕业设计，也适合想系统练一遍SpringBoot全家桶的Java学习者。

1. 项目概述与整体设计思路

1.1 为什么毕设选“SpringBoot + 推荐系统”这个组合

很多同学选毕设题目时容易走入两个极端：一个是纯管理系统，比如“某某信息管理系统”，做出来的东西说白了就是增删改查，功能完整但缺少技术亮点，答辩时老师一问“你这个项目跟别人有什么区别”就哑火了；另一个是纯算法研究，比如“基于深度学习的推荐系统研究”，听起来高大上，但光是把环境跑通、把模型调出结果就要耗掉大半个学期，稍有不慎就烂尾。

电影推荐系统刚好卡在中间。SpringBoot负责把工程化的事情做扎实，推荐算法负责把“亮点”立起来，两头都占，两头又都不会太难。SpringBoot这几年在Java后端几乎是事实标准，自动配置、起步依赖、内嵌Tomcat、丰富的Starter生态，能让你把80%的精力放在业务逻辑和算法实现上，而不是折腾XML配置和容器部署。推荐算法用经典的协同过滤就足够出彩，基于用户的UserCF和基于物品的ItemCF调通之后，再叠加一个热门榜作为冷启动兜底，就能覆盖大部分推荐场景，原理清晰、可解释性强，论文里也好写。

这个组合还很适合“源码+论文”双交付的模式。SpringBoot的代码结构清晰，模块边界分明，适合写成毕业设计论文里的“系统设计”和“系统实现”章节；协同过滤算法的数学原理虽然简单，但推导过程、相似度公式、评分预测公式写进论文里会显得很有学术含量，实际上手写起来也就几十行Java代码的事，答辩演示时也很容易讲清楚。

1.2 核心功能模块拆分

我在做系统设计的时候，把整个项目拆成了四个核心模块，这也是答辩时讲解的主线。

用户模块负责注册、登录、个人信息维护，登录态用JWT做无状态认证，配合拦截器校验接口权限。这里用JWT而不是Session，主要是考虑前后端分离架构下，Session跨域、跨服务共享都比较麻烦，JWT把用户信息加密放在Token里，后端只负责验签，状态天然无痕，部署的时候也方便做水平扩展。

电影模块负责电影信息的管理和展示，包括电影的基本信息、类型分类、上映年份、地区、评分均分等。首页的推荐流、分类浏览、搜索、排行榜全部依赖这个模块的数据输出。数据层面我设计了电影表和电影类型表两张核心表，通过关联表实现多对多的类型关系。

评分模块是推荐系统的“燃料”。用户对电影打分的行为会记录到评分表里，评分数据不仅是推荐算法的输入，也是计算电影均分、生成排行榜的数据来源。这个模块最容易被忽视，但它恰恰是整个系统里最重要的部分，没有评分数据，推荐引擎就是无米之炊。

推荐模块是系统的技术核心。它定时或实时地从评分数据中计算用户相似度或物品相似度，然后为每个用户生成TopN推荐列表，存入缓存或推荐结果表，接口层直接读取结果返回给前端。推荐结果要满足多样性，不能只推同一类型的影片，所以我做了基于类型的打散处理。

1.3 推荐算法选型：从协同过滤到混合推荐

推荐算法这块，我一开始纠结过要不要上深度学习模型，后来果断放弃了，原因有三：一是毕设的数据量撑不起神经网络训练，MovieLens数据集也就几十万条评分，用深度学习属于杀鸡用牛刀；二是深度学习模型的训练和调参周期太长，不确定因素太多；三是答辩时老师更关心你是否理解算法的原理和适用场景，而不是你调参调得多溜。

最后我选择了“基于用户的协同过滤 + 基于物品的协同过滤 + 热门榜单”三条路并行。UserCF适合用户数量相对较少、交互数据密集的场景，它的逻辑是“和你兴趣相似的人喜欢的东西，你也可能喜欢”；ItemCF适合物品数量相对较少、用户行为丰富的场景，它的逻辑是“喜欢过某部电影的人，也可能喜欢与之相似的电影”。在实际项目中，我把UserCF作为主推荐算法输出“猜你喜欢”，ItemCF作为相关推荐输出“看了这部电影的人还看了”，热门榜单作为冷启动兜底，解决新用户没有行为数据的问题。

做混合推荐时我还发现一个重要细节：不要让三种算法的结果混在一起随机展示，应该分区域展示。比如首页从上到下依次是“热门电影”“猜你喜欢”“高分佳作”“同类推荐”，每个区域由不同的算法驱动，这样用户在视觉上能明确感知到不同推荐逻辑的区别，答辩时也更好讲每一块的设计意图。

2. 技术栈选型与数据库设计

2.1 技术栈清单与选型理由

整个项目的技术栈是我反复权衡过的，既要保证开发效率，也要兼顾技术深度。后端主框架就是标题里的SpringBoot，我用的2.7.x版本，稳定且兼容性最好，不会出现网上很多教程里SpringBoot 3.x带来的Jakarta命名空间迁移问题。ORM框架选了MyBatis-Plus，它的LambdaQueryWrapper写起来非常顺手，单表查询基本不用手写SQL，分页插件也内置好了。数据库用MySQL 8.0，缓存用Redis，登录认证用JWT + Spring Interceptor，接口文档用Knife4j（Swagger增强版），前端用Vue 2 + Element UI + Axios。

这套技术栈的特点是：每一项都是当前Java后端的主流标配，面试聊起来有话题，写起来也不至于太折腾。特别是MyBatis-Plus和Redis这两件套，前者能把开发效率提升一大截，后者能为推荐结果的缓存和热门榜单的实时计算提供支撑，这两个点都能在论文里写出东西来。

2.2 核心表结构设计

数据库表我设计了八张，核心是用户表、电影表、评分表，外围是类型表、用户类型关联表、电影类型关联表，再加上操作日志表和推荐结果表。这里贴几张关键表的字段设计，方便你直接照搬。

用户表（user）：

电影表（movie）：

评分表（rating）是推荐算法的核心输入，字段设计直接影响后续计算的效率：

推荐结果表（recommend_result）用来存储离线计算好的推荐列表，避免每次请求都实时算一遍：

一个很容易踩的坑是评分表忘了加联合唯一索引，导致同一用户对同一部电影有多条评分记录，推荐算法计算时会把这个用户的行为权重放大，结果就偏了。建表时一定记得加 (user_id, movie_id) 的Unique约束，并且代码里用INSERT ... ON DUPLICATE KEY UPDATE或者先查再插的方式保持数据幂等。

2.3 数据从哪来：本地数据采集与处理

电影数据是这类系统最让人头疼的问题之一。我调研过爬取某个电影网站的公开数据，但考虑到数据量、合法性、反爬机制和时间成本，最后放弃了实时爬取，改用两个数据源拼装：一份来自MovieLens公开数据集的电影基础信息和评分数据，另一份来自豆瓣/IMDb公开API的电影详情补充。

MovieLens的movies.csv和ratings.csv下载下来之后是CSV格式，我用一个简单的SpringBoot启动时Runner做数据初始化：当数据库为空时，读取classpath下的CSV文件，批量写入电影表和评分表。评分数据是用户行为数据，不需要绝对真实，MovieLens的评分分布比较符合真实场景，正好可以喂给推荐算法训练。电影详情字段我用Python脚本批量处理，把海报URL、导演、演员、简介这些信息格式化整理成SQL脚本，一次性导入数据库。

这里给个建议：数据量不用贪大，我实际用了约6000部电影和20万条评分，跑UserCF时已经能看到不错的推荐效果。数据量太小时算法效果不明显，太多时本地开发机算起来又吃力，6000部电影、20万条评分这个量级是比较舒服的区间。

3. 核心模块实现与实操要点

3.1 环境准备与项目初始化

开发环境我用的是JDK 1.8 + Maven 3.6 + IDEA，数据库为MySQL 8.0，缓存用Redis 5.x。初始化SpringBoot项目时建议直接用Spring Initializr生成，勾选Spring Web、MySQL Driver、MyBatis-Plus、Spring Data Redis、Validation这几个依赖。注意MyBatis-Plus要选3.5.x版本，和SpringBoot 2.7.x的兼容性最好，不要选3.4以下的老版本，API变动比较大。

application.yml里几个关键配置如下：

server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/movie_rec?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai username: root password: root driver-class-name: com.mysql.cj.jdbc.Driver redis: host: localhost port: 6379 database: 0 jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT+8 mybatis-plus: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl map-underscore-to-camel-case: true global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0 jwt: secret: your-secret-key-please-change-in-production expire-hours: 24

这里有两个容易出问题的地方：一是MySQL连接串一定要加serverTimezone=Asia/Shanghai，否则Java 8的时间类型和MySQL的datetime对不上，查询会报时区错误；二是MyBatis-Plus的逻辑删除配置，如果在实体类里加了@TableLogic注解的字段，全局配置里的logic-delete-field要对应上，不然删除操作会变成物理删除，评分数据这种核心数据物理删了可就找不回来了。

3.2 用户登录与权限控制

用户模块我用BCrypt加密存储密码，JWT生成Token，拦截器做统一鉴权。BCrypt加密的好处是每次生成的哈希值都不相同，即使数据库泄露，攻击者也无法通过彩虹表反查出原始密码，这在论文的安全设计部分是个加分项。

JWT的生成逻辑比较简单，我用jjwt库实现，登录成功后把userId和role放进Token的Claims里，设置24小时过期时间。拦截器实现HandlerInterceptor接口，在preHandle方法里从请求头取出Token并解析，解析失败返回401状态码，解析成功把userId放到RequestContext中供后续业务使用。

这里分享一个使用细节：拦截器里放行的路径一定要设计好。我放行的路径包括用户注册、用户登录、电影列表、电影搜索、电影详情和推荐列表，因为这些是游客也能访问的；需要登录的路径包括提交评分、收藏、个人信息修改；管理员专属的路径包括电影管理、用户管理、数据统计。用前缀匹配的方式，比如/admin/**的接口统一校验role是否为管理员，不要在每个Controller里写if判断，代码会干净很多。

3.3 电影检索与评分模块

电影列表页的检索是个很容易被低估的功能。我支持了关键词模糊搜索（匹配片名和演员）、类型筛选、地区筛选、年份区间筛选、排序（按热度、按评分、按上映时间），这些条件组合起来用MyBatis-Plus的LambdaQueryWrapper动态拼接条件。

public Page<MovieVO> searchMovies(MovieQuery query) { LambdaQueryWrapper<Movie> wrapper = new LambdaQueryWrapper<>(); if (StringUtils.hasText(query.getKeyword())) { wrapper.and(w -> w.like(Movie::getTitle, query.getKeyword()) .or().like(Movie::getActors, query.getKeyword())); } if (query.getGenreId() != null) { wrapper.inSql(Movie::getId, "SELECT movie_id FROM movie_genre WHERE genre_id = " + query.getGenreId()); } if (query.getRegion() != null) { wrapper.eq(Movie::getRegion, query.getRegion()); } if (query.getYearFrom() != null && query.getYearTo() != null) { wrapper.between(Movie::getReleaseDate, query.getYearFrom() + "-01-01", query.getYearTo() + "-12-31"); } // 排序：支持hot（热度）、rating（评分）、latest（最新） if ("hot".equals(query.getSort())) { wrapper.orderByDesc(Movie::getRatingCount); } else if ("rating".equals(query.getSort())) { wrapper.orderByDesc(Movie::getAverageRating); } else { wrapper.orderByDesc(Movie::getReleaseDate); } return movieMapper.selectPage(new Page<>(query.getPageNum(), query.getPageSize()), wrapper); }

评分模块的逻辑简单但有个细节要注意：用户重新评分时要覆盖旧记录，而不是插一条新记录。我在Service层里实现了upsert逻辑，先通过userId和movieId查是否存在记录，存在则更新score和update_time，不存在则新增。更新完评分之后，还要同步更新movie表的average_rating和rating_count字段。这里我用了一个简单的SQL：average_rating = (average_rating * rating_count + 新评分) / (rating_count + 1)，新增时用这个公式，更新时则要先把旧的评分从平均值里扣掉再加新的。这个小细节如果面试被问到“如何维护冗余的统计字段”，会是很加分的回答。

3.4 推荐引擎的实现细节

推荐引擎是系统的心脏，也是论文的核心章节。我采用的UserCF算法步骤可以拆成四步：

第一步，构建用户-物品评分矩阵。我从rating表里把最近30天的有效评分记录加载到内存，用Map<Long, Map<Long, Double>>结构表示，外层Key是用户ID，内层Key是电影ID，Value是评分值。

第二步，计算用户之间的相似度。我用的是皮尔逊相关系数，公式为：sim(u, v) = Σ((r_ui - r̄_u) * (r_vi - r̄_v)) / (sqrt(Σ(r_ui - r̄_u)²) * sqrt(Σ(r_vi - r̄_v)²))。两个用户共同评过分的电影越多，评分趋势越一致，相似度越高。这里要注意的是，皮尔逊相关系数需要先计算两个用户各自的评分均值，没有共同评分项的用户对直接跳过，不需要计算。

public Map<Long, Double> calUserSimilarity(Map<Long, Map<Long, Double>> userRatings, Long targetUserId) { Map<Long, Double> simMap = new HashMap<>(); Map<Long, Double> targetRatings = userRatings.get(targetUserId); if (targetRatings == null) return simMap; double targetAvg = targetRatings.values().stream().mapToDouble(Double::doubleValue).average().orElse(0.0); for (Map.Entry<Long, Map<Long, Double>> entry : userRatings.entrySet()) { Long otherUserId = entry.getKey(); if (otherUserId.equals(targetUserId)) continue; Map<Long, Double> otherRatings = entry.getValue(); // 取共同评分的电影 List<Map.Entry<Long, Double>> commonItems = targetRatings.entrySet().stream() .filter(e -> otherRatings.containsKey(e.getKey())) .collect(Collectors.toList()); if (commonItems.size() < 2) continue; double otherAvg = otherRatings.values().stream().mapToDouble(Double::doubleValue).average().orElse(0.0); double numerator = 0.0, denominator1 = 0.0, denominator2 = 0.0; for (Map.Entry<Long, Double> item : commonItems) { double targetDiff = item.getValue() - targetAvg; double otherDiff = otherRatings.get(item.getKey()) - otherAvg; numerator += targetDiff * otherDiff; denominator1 += targetDiff * targetDiff; denominator2 += otherDiff * otherDiff; } if (denominator1 == 0.0 || denominator2 == 0.0) continue; double sim = numerator / (Math.sqrt(denominator1) * Math.sqrt(denominator2)); simMap.put(otherUserId, sim); } return simMap; }

第三步，选取K个最近邻。我取相似度最高的前20个用户作为最近邻集合，这个K值是通过多次实验得到的：K太小推荐结果不稳定，K太大推荐结果会偏向热门电影。用20这个值在6000部电影、20万条评分的数据集上效果比较均衡。

第四步，预测目标用户对未评分电影的评分，生成TopN推荐。预测公式是加权平均：pred(u, i) = r̄_u + Σ(sim(u, v) * (r_vi - r̄_v)) / Σ(sim(u, v))。然后去掉用户已经看过的电影，按预测评分从高到低排序，取前20部作为推荐结果。注意预测时要从分母和分子里过滤掉用户已评分过的电影，否则推荐列表里会出现用户已经看过的片子，体验很不好。

ItemCF的实现逻辑类似，只是相似度计算的对象从用户变成了电影。两个电影被同一批用户喜欢，它们就越相似。在“看了这部电影的人还看了”这个场景中，ItemCF的效果明显好于UserCF，因为它能捕捉到物品之间的静态关联关系。

3.5 管理后台与数据可视化

管理后台是答辩时最容易出效果的部分。我实现了统计面板，展示用户总数、电影总数、评分总数、当日新增用户数等基础指标，用ECharts绘制了简单的趋势图。这些数据从数据库里查出来聚合一下就能展示，技术难度不高，但视觉效果很好，能直观地说明系统在真实运行。

电影管理模块支持后台添加、编辑、下架电影。这里有一个细节：后台操作要记录操作日志，用AOP切面统一处理。我在自定义注解@OperationLog上标注操作方法，通过切面解析注解并记录操作类型、操作人、操作时间、请求参数，写入日志表。这个功能虽然不起眼，但放在论文的“系统安全性设计”章节里是个很好的补充。

4. 前后端联调与部署上线

4.1 接口设计规范与联调细节

前后端联调阶段最容易出现的矛盾就是接口返回格式不统一。我为了省事，项目一开始就封装了统一的返回对象Result<T>，结构为{ code: 200, message: "success", data: ... }。所有Controller的返回值类型都是Result ，通过全局异常处理器把业务异常也包装成相同的格式返回。前端Axios的响应拦截器统一判断code，约定code为200表示成功，401表示Token失效需要重新登录，500表示服务器内部错误。这样前后端沟通成本大大降低，联调效率提升了不止一倍。

跨域问题也是前后端分离项目的老大难。我在后端配置了WebMvcConfigurer的CORS规则：允许前端地址（http://localhost:3000）跨域，允许的请求方法为GET、POST、PUT、DELETE、OPTIONS，允许携带凭证。如果你用Nginx做反向代理，其实可以省掉这个配置，直接由Nginx转发请求。但本地开发时还是保留跨域配置更方便。

需要注意的一点是，SpringBoot处理OPTIONS预检请求时要放行，否则前端浏览器会拦截真正的业务请求。我在拦截器里加了判断，如果请求方法是OPTIONS，直接返回true不拦截。

4.2 本地打包部署与运行参数调优

项目开发完成后，我把前端项目构建后的静态文件复制到了SpringBoot的src/main/resources/static目录下，这样整个系统就变成了一个可直接运行的Jar包，省去了单独部署Nginx的麻烦。打包命令很简单：

mvn clean package -DskipTests java -jar movie-recommend-system.jar --spring.profiles.active=prod

这里有个坑：如果你把前端静态文件放在static目录下，后端接口路径和前端路由不能冲突。我前端用的是history模式路由，刷新页面时会出现404。解决方案是配置一个资源映射和转发规则，在后端拦截所有非接口路径的请求，转发到index.html：

@Configuration public class WebConfig implements WebMvcConfigurer { @Override public void addViewControllers(ViewControllerRegistry registry) { registry.addViewController("/{spring:[^\\.]*}").setViewName("forward:/index.html"); } }

部署时JVM参数也可以调优，我加了-Xms512m -Xmx1024m，堆内存初始和最大分别设置，避免频繁扩容；-XX:+UseG1GC使用G1垃圾回收器，比默认的Parallel GC更适合这种聚合计算型任务。数据库连接池我用的HikariCP（SpringBoot默认），maximum-pool-size设置为20足够，推荐任务跑批时单独开了个线程池，避免阻塞业务请求。

4.3 推荐性能优化的几个维度

推荐系统的性能优化是我花了最多时间打磨的部分，因为第一次跑UserCF时，实时计算20万条评分的相似度矩阵，耗时接近10秒，用户根本等不起。我采用了三层优化思路。

第一层，离线计算 + 缓存预热。把相似度矩阵和推荐结果做成离线任务，用户注册或评分变化时触发增量更新。大部分推荐场景对实时性要求并不高，用户今天打的分明天才反映到推荐列表里完全能接受。我在项目启动时用ApplicationRunner把所有用户的推荐结果批量计算一次，存入Redis，过期时间24小时。用户请求推荐接口时直接查Redis，命中率在95%以上。

第二层，数据过滤。计算相似度之前，先过滤掉评分记录少于5条的用户，这些用户的评分行为太稀疏，计算出的相似度噪声很大，还会拖慢计算速度。同时过滤掉评分人数少于10的电影，这些电影可能是测试数据或异常数据。过滤之后参与计算的评分条数从20万降到15万，相似度的准确性反而提升了。

第三层，并行计算。用Java的ForkJoinPool把用户相似度计算任务按用户ID分片并行执行。我的开发机是8核CPU，通过并行把计算耗时从10秒降到了2.5秒左右。虽然离线计算不用太在乎耗时，但迭代调参时的体验感差别很大，谁也不想改一次参数等半分钟。

5. 常见问题与避坑实录

5.1 协同过滤的冷启动问题与兜底方案

协同过滤算法最大的缺陷就是冷启动：新用户没有任何评分行为，系统无法计算他的相似用户，推荐列表自然为空。新上线的电影没有用户评分，ItemCF也无法把它推荐出去。

我的解决方案是分层兜底。新用户第一次访问首页时，直接从Redis读取热门电影榜单作为推荐内容，热门榜单按30天内评分人数排序，配合“本周热映”和“高分佳作”两个榜单交叉展示。用户评分达到5条后，系统才启用UserCF生成个性化推荐。这个策略在代码里体现为推荐接口的一个分支判断：if (ratingCount < 5) return hotMovies;。新电影则通过Admin后台手动设置is_hot标签，强制在热门榜单中曝光一段时间。

5.2 数据稀疏与相似度计算的坑

即使有了MovieLens的20万条评分数据，用户-电影评分矩阵依然非常稀疏，大约98%的位置是空的。稀疏矩阵带来的最大问题是，很多用户之间没有共同评分过的电影，相似度计算结果为0，白白浪费计算资源。除了前面说的过滤策略，我还用了“基于物品的协同过滤”作为UserCF的补充。ItemCF对稀疏数据的容忍度更高，因为电影的总数远小于用户数，两两电影之间的共同评分用户更容易找到。

另一个容易被忽视的坑是预测分数可能出现负值或超过5分。皮尔逊相关系数计算出的相似度可能是负值，加权后可能导致预测评分很低甚至为负。处理方案是，过滤掉相似度为负值的用户对，只保留正相关的最近邻；预测评分最终用Math.max(1, Math.min(5, predScore))限制在1到5的范围内，避免评分越界污染展示数据。

5.3 SpringBoot版本升级带来的兼容性问题

我在开发过程中频繁遇到网上教程的代码跑不通的情况，排查下来大多数是SpringBoot版本差异导致的。SpringBoot 2.3版本之后，spring.factories自动配置机制逐步被AutoConfiguration.imports替代；SpringBoot 3.0版本则全面转向Jakarta命名空间，javax.*包全部不可用，很多老教程的代码直接编译不过。

我的建议是锁定SpringBoot 2.7.x版本作为毕设项目的基线，这个版本处于2.x时代的末期，既没有3.x的新命名空间坑，也对主流第三方库兼容得最好。如果遇到第三方Starter的兼容问题，优先排查版本冲突。比如Redis的客户端从Jedis换成了Lettuce，连接池配置项从jedis.变成了spring.data.redis.lettuce.pool.，这个配置写错会导致启动不报错但Redis连接不上的诡异问题。

5.4 推荐结果为空或质量差时的排查清单

如果你的推荐接口返回的结果为空，或者结果质量差得离谱，我建议按下面的顺序排查：

先确认评分数据是否真的写入成功了，很多时候是评分表里的userId或movieId外键不对，导致SQL查询返回空；再确认相似度计算的输入是否正确打印了日志，比如用户数量、评分矩阵的大小；接着确认过滤条件是否误伤了正常数据，比如把评分人数小于10的电影过滤掉之后，如果数据量本来就小，可能剩下的电影连20部都不够推荐；最后检查推荐结果缓存是否已经过期，Redis里的数据过期后如果定时任务没有触发，接口就会查不到缓存也不走实时计算，返回空列表。

写在最后

做完这个项目后，我对SpringBoot生态和推荐算法的理解都深入了一个层次。以前只是会用MyBatis-Plus写CRUD，做完之后才明白什么是模块划分、什么是缓存策略、什么是性能瓶颈。这个项目面试的时候特别好讲，从协同过滤的原理到SpringBoot的自动配置，从Redis的缓存设计到JWT的鉴权流程，每一个点都能展开聊上几分钟。如果你也正在做这个题目，我建议你千万不要停留在把代码跑通这个层面，一定要亲手写一遍相似度计算和评分预测的核心代码，然后试着调一下K值、过滤条件这些参数，观察推荐结果的变化。这些折腾的过程，才是你做这个项目最大的收获。

最后分享一个小技巧：答辩演示的时候，提前准备几个已经打过分的测试账号，一个账号只看动作片，一个账号只看爱情片，一个账号只看文艺片，然后切换账号展示推荐结果的差异。这个演示效果比讲任何原理都直观。做推荐系统，最怕的就是口若悬河地讲完算法，一打开系统推荐的全是榜单热片，那场面就尴尬了。