SpringBoot电影推荐系统：从协同过滤到项目落地

1. 选题拆解：电影推荐系统背后到底在考察什么能力

每年到了毕业设计季，SpringBoot电影推荐系统都是Java方向的高频选题。这个题目能一直火，并不是因为论坛上流传的源码特别多，而是因为它确实有内在的合理之处：一个完整的前后端分离项目该有的模块它基本都有，数据库设计有一定复杂度，又能自然引入推荐算法这种能拿得出手的差异化亮点。换句话说，一套这样的系统既能检验SpringBoot的基础功底，又给"如何做得比别人好"留足了空间。

1.1 题目的核心考察点

很多同学拿到这个题目后的第一反应是去搜源码，搜完就准备直接改个名字交上去。但真正到了答辩环节，老师问的第一个问题往往就会把你卡住——"你这个推荐是怎么实现的？"

我见过太多类似的场景。所以先说清楚，这个题目真正考察的能力有三层：

第一层是SpringBoot的基本功。包括自动装配的理解、常用注解的使用、分层架构的规范（Controller、Service、Mapper三层的职责划分）、统一异常处理、拦截器或过滤器做鉴权等。这些是及格线。

第二层是数据库设计能力。电影表、用户表、评分表、收藏表、分类表、轮播图表等等，表与表之间是什么关系，索引该怎么建，评分和收藏这种用户行为数据如何跟电影信息关联。这些细节做好了，项目才谈得上"可用"。

第三层是推荐算法的理解与落地。你不需要发明新算法，但至少得能说清楚协同过滤的思路，知道基于用户的推荐和基于物品的推荐分别适用于什么场景，以及冷启动问题怎么处理。这一层是拉开差距的地方。

1.2 用户角色与功能边界

按照常规毕业设计的体量，这个系统我建议划分为两个端：用户端和管理员端。

用户端的核心功能包括注册登录、电影列表展示、电影详情查看、搜索、评分、收藏、推荐列表、个人中心。管理员端的核心功能包括电影管理（增删改查、上下架）、分类管理、用户管理、评分管理、轮播图管理、推荐参数配置。

我用表格把这套常见功能边界列出来，方便对照：

1.3 评审老师最关注什么

基于我带项目的经验，评审老师在毕业设计中会重点看几个方面：一是系统能不能跑起来，二是功能是否完整闭环，三是有没有展示自己的思考。

所谓的"闭环"，指的是用户从注册、登录、浏览电影、给电影打分，到系统基于评分数据给出推荐，这样一个完整的业务链路是通的。很多源码在这个地方是断裂的——评分功能有了，但推荐模块不读取评分数据，而是直接用随机数据填充。这样做，功能列表虽然完整，但答辩一追问就会露馅。

所以在设计阶段就要想清楚：推荐模块的数据来源是什么、推荐结果跟评分行为之间如何关联、冷启动阶段推什么内容。这些内容会贯穿在后续的开发和论文撰写中。

2. 技术选型：SpringBoot生态下的务实搭配

技术选型的核心原则是"稳"字当头。毕业设计（或者简历上的项目）需要的不是一个花哨的架构，而是一套你能讲清楚、能顺利跑起来、遇到问题能排查的方案。

2.1 框架选择与版本搭配

后端推荐使用SpringBoot 2.7.x系列，原因很直接：稳定、资料多、跟多数教程对得上。SpringBoot 3.x确实出来了，但它的底层是Jakarta EE规范，JDK要求17+，MyBatis-Plus适配上偶尔会踩版本坑。如果你只是做一个毕设或课程设计，没必要为了追新版本给自己添麻烦。

这里插一句很多同学问到的问题——"SpringBoot版本太高怎么办"。实际场景是你在网上看到别人的项目用的2.3.5，你自己本地装了3.1.0，跑起来各种报错，找原因折腾半天。最省事的做法就是直接切换JDK和Maven配置，让本地环境和项目保持一致。SpringBoot版本和JDK版本的对应关系大致是：2.x系列支持JDK8/11，3.x系列要求JDK17起步。准备环境之前先确认这层关系，能少踩很多坑。

ORM层面我推荐MyBatis-Plus。相比纯MyBatis，它最大的优势是内置了通用的增删改查方法，单表操作不需要写SQL。推荐系统的核心查询场景——按用户查评分、按电影查平均分、批量查电影信息——MyBatis-Plus的LambdaQueryWrapper用起来非常顺手。

2.2 数据库设计与关键表结构

数据库我用的MySQL 5.7或8.0都可以。核心表设计上，建议至少包含以下这几张：

• t_user（用户表）：id、用户名、密码、昵称、头像、角色（user/admin）、注册时间
• t_movie（电影表）：id、电影名称、导演、主演、类型、简介、封面地址、上映年份、地区、评分均值、评分人数
• t_rate（评分表）：id、用户id、电影id、评分值、创建时间、更新时间

这里t_rate表是推荐算法的数据基础，需要特别注意。评分表的唯一约束要建立在"用户id+电影id"这个组合上，防止同一个用户对同一部电影重复评分。MySQL里可以用联合唯一索引来实现：

sql复制ALTER TABLE t_rate ADD UNIQUE KEY uk_user_movie (user_id, movie_id);

t_movie表里冗余了"评分均值"和"评分人数"两个字段。很多新手会忽略这两个字段，每次展示电影列表时都用AVG()实时计算。当评分数据量上来之后，这种做法会让列表页的SQL非常慢。用冗余字段，在用户提交评分时同步更新，是工程上更合理的做法。

2.3 缓存组件怎么选

推荐系统里有一个天然适合用缓存的场景：推荐结果列表。如果每次用户打开"猜你喜欢"页面都要实时计算一遍相似度和排序，响应时间会很不理想。所以需要引入Redis做结果缓存。

Redis在这个项目里的定位有两个：一是缓存推荐结果，减少重复计算；二是保存用户的登录态（Token）。如果对Redis不熟悉，也可以先用SpringBoot自带的Caffeine做本地缓存。但考虑到Redis在简历上是加分项，而且SpringBoot整合Redis非常方便，建议直接用Redis。

推荐结果缓存的key我建议设计成这样：recommend:user:{userId}，value用JSON数组保存推荐电影id列表，过期时间设置为3小时。这样用户短时间内多次刷新页面，都能命中缓存，不用重复计算。

2.4 前端方案的选择

前端有两种选择：一是用Thymeleaf做服务端渲染，整体项目打包成一个jar包部署；二是用Vue + Element UI做前后端分离，前端单独跑在Node环境或者打包后放入SpringBoot的static目录。

对于毕业答辩，我个人的建议是：如果时间紧张或者前端基础一般，直接选Thymeleaf方案，省心、部署简单；如果前端有一定基础，想给项目加分，采用Vue前后端分离。很多网上的源码是基于Vue的，但材质参差不齐，跑起来问题不少。实际选择时，以"能跑通"为最高优先级。

3. 推荐算法落地：从协同过滤到混合推荐的实践路径

推荐算法是整个系统里最值得详写的部分，也是答辩时老师最容易提问的点。

3.1 算法选型的判断依据

在电影推荐场景中，业界最常用的入门算法是协同过滤（Collaborative Filtering，简称CF）。协同过滤分两类：基于用户的协同过滤（UserCF）和基于物品的协同过滤（ItemCF）。

基于用户的协同过滤的核心思想是"物以类聚，人以群分"——找到与当前用户兴趣相似的其他用户，把这些相似用户喜欢的电影推荐给当前用户。基于物品的协同过滤的核心思想是"喜欢这个电影的人，通常也会喜欢那部电影"——找出与用户历史上喜欢过的电影相似的电影来做推荐。

在电影场景中，我建议优先使用ItemCF。原因有两个：第一，电影数量相对用户数量要少得多，物品之间的相似度矩阵可以用离线任务计算好，在线推荐时直接查表；第二，用户的兴趣会随着时间变化，用UserCF可能出现"昨天喜欢A类电影，今天已经被推荐同一类电影"的僵化问题，而ItemCF能更及时地基于用户最近的评分行为做调整。

3.2 基于物品的协同过滤实现细节

ItemCF的实现分两个阶段。离线计算阶段，根据所有用户的评分数据，计算电影之间的相似度矩阵。在线推荐阶段，拿到用户的评分记录，找出用户高分评价过的电影，基于相似度矩阵找出这些电影的近邻电影，按相似度加权排序后输出。

计算电影之间相似度的常见公式是余弦相似度。电影的评分向量可以看作一个稀疏向量，比如电影A的评分向量是[用户1:5, 用户3:4, 用户7:2]，电影B的评分向量是[用户1:4, 用户3:5, 用户8:3]。需要说明的是，余弦相似度在计算时只考虑共同评分的用户维度。

在实际代码中，我用Java实现了一个简化版本。核心思路是先用Map把每个电影被哪些用户评过分、评了多少分存起来，再对任意两部电影计算共同评分用户集合，套用余弦相似度公式。

java复制public Map<Long, Map<Long, Double>> computeItemSimilarity(List<Rating> ratings) {
    // key: userId, value: Map<movieId, score>
    Map<Long, Map<Long, Double>> userMovieMap = new HashMap<>();
    for (Rating r : ratings) {
        userMovieMap.computeIfAbsent(r.getUserId(), k -> new HashMap<>())
                .put(r.getMovieId(), r.getScore());
    }

    // 构建电影评分向量：key: movieId, value: Map<userId, score>
    Map<Long, Map<Long, Double>> movieUserMap = new HashMap<>();
    for (Map.Entry<Long, Map<Long, Double>> entry : userMovieMap.entrySet()) {
        Long userId = entry.getKey();
        for (Map.Entry<Long, Double> me : entry.getValue().entrySet()) {
            movieUserMap.computeIfAbsent(me.getKey(), k -> new HashMap<>())
                    .put(userId, me.getValue());
        }
    }

    Map<Long, Map<Long, Double>> similarityMatrix = new HashMap<>();
    List<Long> movieIds = new ArrayList<>(movieUserMap.keySet());
    for (int i = 0; i < movieIds.size(); i++) {
        for (int j = i + 1; j < movieIds.size(); j++) {
            Long movieA = movieIds.get(i);
            Long movieB = movieIds.get(j);
            Map<Long, Double> vectorA = movieUserMap.get(movieA);
            Map<Long, Double> vectorB = movieUserMap.get(movieB);
            double dotProduct = 0.0;
            double normA = 0.0;
            double normB = 0.0;
            for (Map.Entry<Long, Double> e : vectorA.entrySet()) {
                normA += e.getValue() * e.getValue();
                if (vectorB.containsKey(e.getKey())) {
                    dotProduct += e.getValue() * vectorB.get(e.getKey());
                }
            }
            for (Double value : vectorB.values()) {
                normB += value * value;
            }
            if (normA == 0.0 || normB == 0.0) {
                continue;
            }
            double similarity = dotProduct / (Math.sqrt(normA) * Math.sqrt(normB));
            similarityMatrix.computeIfAbsent(movieA, k -> new HashMap<>()).put(movieB, similarity);
            similarityMatrix.computeIfAbsent(movieB, k -> new HashMap<>()).put(movieA, similarity);
        }
    }
    return similarityMatrix;
}

这段代码是入门级的实现，放在项目里有两个明显的问题：一是双重循环的时间复杂度是O(n²)，电影数量到几千部的时候还能接受，到几万部就扛不住了；二是评分向量没有做归一化处理，用户打分尺度不一致会对相似度结果产生干扰。

3.3 相似度计算的优化思路

针对上面的问题，实际项目中可以通过两个手段优化。

第一个手段是修正余弦相似度，也就是在计算之前，先对每个用户的评分做均值中心化。比如用户A平均打分4.2，给某部电影打了5分，那么归一化后的分差就是0.8。这样一来，宽松打分和严格打分的用户在同一个尺度上了。推荐算法领域有个常用的做法：在代码实现时，先计算每个用户的平均分，然后从该用户的所有评分中减去平均分，再代入余弦相似度公式。

第二个手段是限制候选集。不要对全量电影做两两计算，而是只对"同时被用户评分过"的电影对计算相似度。实现这个逻辑的方式是：从用户-电影倒排表出发，生成共现电影对，再对共现电影对计算相似度。这样能够把计算量从O(n²)降到有效共现对的数量级。

3.4 冷启动问题的三种处理思路

协同过滤算法有一个天然的缺陷——冷启动。新用户没有任何评分数据，系统无法计算他的兴趣；新上映的电影没有用户评分，系统无法把它推荐出去。

针对冷启动，我在实践中总结了三种简单有效的方案。

第一种是热度推荐。用户登录后如果评分记录为空，直接返回当前评分人数最多、评分最高的热门电影榜单。这个方案实现最简单，效果也最稳妥。

第二种是类别偏好引导。在用户注册时让用户选择自己感兴趣的电影类型（可选3到5个），系统根据类型筛选热门电影进行推荐。这种方式把冷启动问题转化为一个分类匹配问题，在毕业设计里用起来效果很好。

第三种是基于内容的推荐。新电影虽然没有评分，但它的导演、主演、类型标签是齐全的。根据用户历史评过高分的电影的标签，去匹配标签相似的新电影。这套方案需要给电影打标签，前期数据准备工作会多一些，但写进论文里非常有亮点。

实际项目中，可以采用"热度推荐兜底 + 注册时选偏好 + 评分后切换到协同过滤"的三段式策略。

3.5 离线计算与在线推荐的拆分

为了让项目结构更清晰，也为了在答辩时能讲出"耗时任务离线化"的思路，我建议把推荐过程拆成两块。

离线部分负责定时计算物品相似度矩阵和热门电影榜单，计算完成后写入Redis或者数据库的中间表。比较常见的实现方式是使用SpringBoot的@Scheduled定时任务，每天凌晨执行一次全量计算。

在线部分负责根据当前用户的请求，实时读取用户最近的评分记录，结合已经算好的相似度矩阵，组装推荐结果。推荐结果的组装过程是：取用户最近N条评分记录（比如N=6），找到每条记录对应电影的TopK近邻（比如K=8），按相似度加权汇总，剔除用户已经看过的电影，取前20部返回。

这样一个拆分，既解决了性能问题，又让项目的代码结构非常清晰。答辩时可以明确地说：耗时任务通过定时任务离线完成，在线接口只做查询和组装，所以响应速度快。

4. 核心功能模块开发实录

这一部分我会重点讲几个在源码中容易被忽略、但实际开发中非常关键的功能点。

4.1 用户认证与全局拦截

登录认证我采用的是JWT + 拦截器的方式，这也是当前SpringBoot项目的主流做法。用户登录成功后生成一个Token返回给前端，前端在后续请求的Header中带上Token，后端拦截器校验Token合法性与有效期。

使用@Interceptor实现登录拦截时，有几个容易踩的坑。第一个是放行路径的配置——静态资源、登录接口、注册接口、电影列表等公共接口要放行，用户中心、评分、收藏等接口必须拦截。第二个是Token过期的处理——拦截器抛出业务异常后，需要配合@RestControllerAdvice做全局异常捕获，统一返回401状态码。

这里给一个拦截器配置的关键代码片段：

java复制@Configuration
public class WebConfig implements WebMvcConfigurer {
    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        registry.addInterceptor(new LoginInterceptor())
                .addPathPatterns("/api/**")
                .excludePathPatterns("/api/user/login", "/api/user/register")
                .excludePathPatterns("/api/movie/list", "/api/movie/detail/**")
                .excludePathPatterns("/swagger-resources/**", "/doc.html");
    }
}

4.2 电影浏览、评分与收藏闭环

电影详情页通常是用户评分的入口。用户给一部电影打分后，后端要做两件事：一是往t_rate表插入或更新记录，二是同步更新t_movie表中的评分均值。

评分均值的更新逻辑需要做成事务。这里有一个常见的并发问题：当多个用户同时对同一部电影打分时，如果都用"先查询当前均值，再加新评分重新计算"的方式更新，会出现覆盖更新的问题。我的解决方式是直接用SQL原子更新，或者引入分布式锁（用Redis的Redisson，或者数据库悲观锁）。

SQL原子更新的写法可以让评分均值交由数据库自己维护：

sql复制UPDATE t_movie
SET score_sum = score_sum + #{score},
    score_count = score_count + 1
WHERE id = #{movieId};

然后列表展示时，均值可以用score_sum / score_count计算得出。这种写法彻底避免了并发场景下的竞态问题。

收藏功能相对独立，核心就是t_favorite表，字段为id、用户id、电影id、收藏时间。收藏状态用SELECT 1 FROM t_favorite WHERE user_id = ? AND movie_id = ?判断，查询时命中联合索引即可。

4.3 推荐列表的组装与排序

推荐接口是本系统最核心的接口。它接收当前的用户id，返回一个推荐电影列表。处理逻辑分为三步。

第一步，检查Redis缓存中是否有该用户的推荐结果。如果有，直接返回。

第二步，如果没有缓存，从数据库读取用户的评分记录，如果没有评分记录，返回热门电影列表。

第三步，根据评分记录和相似度矩阵，计算候选电影得分。得分计算方式是：对用户评过分的每部电影，找到它的TopK近邻，累加"近邻电影与已评电影相似度 × 用户对已评电影的评分（归一化后）"。汇总候选电影的得分后，剔除用户已评过分的电影，按得分降序取出前20部，写入Redis缓存，然后返回给前端。

候选集得分的Java实现大致是这样的：

java复制public List<Long> recommendForUser(Long userId, int topN) {
    List<Rating> userRatings = ratingMapper.selectByUserId(userId);
    if (userRatings == null || userRatings.isEmpty()) {
        return getHotMovies(topN);
    }
    Map<Long, Double> scoreMap = new HashMap<>();
    for (Rating r : userRatings) {
        Map<Long, Double> neighbors = similarityService.getTopK(r.getMovieId(), 8);
        for (Map.Entry<Long, Double> entry : neighbors.entrySet()) {
            Long movieId = entry.getKey();
            if (userRatedMovieIds.contains(movieId)) {
                continue;
            }
            double sim = entry.getValue();
            double addScore = sim * r.getScore();
            scoreMap.merge(movieId, addScore, Double::sum);
        }
    }
    return scoreMap.entrySet().stream()
            .sorted((a, b) -> Double.compare(b.getValue(), a.getValue()))
            .limit(topN)
            .map(Map.Entry::getKey)
            .collect(Collectors.toList());
}

建议在推荐列表的返回结果里带上"推荐理由"，比如"因为你看过《星际穿越》"。这个小设计在答辩时很加分，能体现你对用户体验的考虑。

4.4 后台管理的权限控制

管理员操作接口跟用户接口必须做权限隔离。实现方案是：在JWT中携带角色字段，在拦截器中判断当前用户是否为admin角色。也可以在管理端接口的路径上统一加/admin/前缀，由独立的拦截器负责校验。

SpringBoot集成Spring Security是更系统的方案，但学习成本偏高。如果只是毕业设计，基于JWT角色判断的轻量方案完全够用，也更好向评审老师讲清楚原理。

5. 踩坑实录：从源码跑通到性能优化的实战经验

最后一个部分，我把实操中频繁遇到的坑集中梳理一遍。这些问题在网上的源码中经常遇到，也是很多同学"跑不起来"的根源。

5.1 换电脑就跑不起来的环境问题

下载了源码之后，跑不起来的原因八成集中在三个方面：JDK版本不一致、MySQL版本和连接配置问题、Maven依赖下载失败。

SpringBoot不同版本对JDK的要求不同。如果项目是SpringBoot 2.x，本地安装JDK 8或11基本都能跑。如果项目是SpringBoot 3.x，JDK 17以上才行。环境变量要确认系统里生效的是哪个JDK，命令行执行java -version看一下就清楚了。

MySQL连接这一块，需要检查配置文件中数据库地址、用户名、密码是否和本地一致。如果本地的MySQL是8.0，驱动参数driver-class-name要改为com.mysql.cj.jdbc.Driver，URL中最好加上useSSL=false&serverTimezone=Asia/Shanghai。还有一点，MySQL 8.0的默认认证插件是caching_sha2_password，老版本的连接驱动可能不支持，如果遇到Authentication plugin报错，可以在MySQL中把用户认证插件改回mysql_native_password。

Maven依赖下载失败这个问题，优先检查IDEA中Maven的配置是使用本地仓库还是默认仓库。国内网络环境下，最推荐配置阿里云的Maven镜像，把settings.xml中的mirror指向阿里云仓库后，依赖下载速度会明显提升。

5.2 推荐结果质量不理想的原因

很多同学跑通推荐模块后，发现推荐结果"不准"。比如用户明明只看了几部科幻片，推荐列表里什么类型都有。这个问题的根源通常在于数据的稀疏性——用户评分数据太少，相似度矩阵不可靠。

解决思路有两个。第一个是降低对协同过滤结果的依赖，把推荐列表中插入一部分热度推荐，做混合策略。第二个是引入类型标签过滤规则——用户评过高分的电影类型作为白名单，推荐候选集先按类型过滤，再做协同过滤排序。这种"规则前置 + 算法排序"的组合在实际中效果提升非常明显。

5.3 接口响应变慢后的优化路线

系统跑通之后，如果数据量增大，接口响应会变慢。优先检查SQL的执行计划。使用MyBatis-Plus时，可以开启控制台SQL日志打印，观察到评分查询、电影批量查询等SQL的执行时间。

优化思路按优先级排序：先加索引，特别是t_rate表的user_id和movie_id；再优化查询逻辑，比如用IN批量查询代替循环单条查询；然后引入缓存，比如电影详情信息适合用Redis做缓存；最后才考虑代码层面的算法优化。千万不要一上来就改推荐算法，很可能不是算法的瓶颈。

5.4 前后端联调的跨域问题

前后端分离项目中，前端启动在8080端口，后端启动在9090端口，浏览器跨域请求会被拦截。解决方式是在SpringBoot中配置CORS跨域规则。

java复制@Configuration
public class CorsConfig implements WebMvcConfigurer {
    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/**")
                .allowedOrigins("http://localhost:8080")
                .allowedMethods("GET", "POST", "PUT", "DELETE")
                .allowedHeaders("*")
                .allowCredentials(true);
    }
}

这里有一个特别容易被忽略的坑：如果拦截器配置了跨域规则放行，但JWT拦截器对OPTIONS预检请求返回了401，前端依然会报跨域错误。正确的做法是在登录拦截器中直接放行所有OPTIONS请求，预检请求不参与业务鉴权。

5.5 部署时容易忽略的问题

本地跑通之后，很多同学会把项目打包成jar包放到服务器上。此时最容易遇到两个问题。第一个是打包时会把前端页面一起打进去，所以要确认pom.xml中前端静态资源的构建配置是否正确。第二个是服务器上的MySQL和Redis都需要开放对应的端口访问权限，并且检查防火墙和安全组规则。

数据库初始化时，建议使用项目中的SQL脚本一次性导入表结构和初始数据。如果脚本中包含了中文字段（例如电影简介、导演名），在Linux服务器上导入时需要注意文件编码统一为UTF-8，否则会出现乱码。

最后再分享一点我个人的体会。做这种带推荐算法的系统，最大的收获往往不是在"能跑通"这一步，而是在"能跑得更好"的过程中。把推荐结果的展示加上推荐理由、把冷启动策略做成可配置、给管理后台增加数据统计图表，这些细节不需要太多额外工作量，但会让整个项目的完成度上一个台阶。如果你正在做类似的选题，建议优先把基础的协同过滤链路跑通，再逐步丰富细节。祝顺利。