基于SpringBoot的电影推荐系统：协同过滤与冷启动策略实战

1. 项目定位与整体方案拆解

1.1 毕设级电影推荐系统究竟要做哪些事

如果你正处于毕业设计选题阶段，想做一个“看起来有技术含量、但又不会把自己困死在算法深水区”的系统，电影推荐是一个非常经典的落点。它既有明确的应用场景，又有足够的功能广度：用户注册、电影浏览、评分评论、收藏管理和推荐榜单，每一个模块都能掰开讲清楚，而推荐算法这个点又天然具备“论文亮点”。

拿我现在要拆解的这套基于SpringBoot技术的电影推荐系统来说，它并不是一个单纯增删改查的管理系统，而是把“记录用户行为”和“利用行为数据反哺用户体验”两个环节串了起来。用户在前台给电影打分、留下评论，系统后台根据这些历史行为用协同过滤和基于内容的策略计算相似度，再把用户可能感兴趣的电影推送到推荐列表。

这种设计的典型工作流是这样的：用户登录后进入首页，先看到一轮影片聚合展示，可能是热门榜、新片榜，也可能是算法推荐的“为你推荐”。用户点进某一部电影详情页后，可以看到影片类型、导演、主演、简介，还能给这部电影打1-5星的评分，或者发一段短评。评分和评论会写进行为日志，成为后续推荐的输入数据。

从毕设答辩的角度讲，这套系统覆盖了“前端交互-后端接口-数据库设计-推荐算法-系统部署”整条链路，每一层都有可以深挖的细节。从源码归档的角度讲，它也不是一个演示用的demo，而是一套可以真正跑起来、局部定制后直接提交的作品。

1.2 技术选型为什么锁定Spring Boot

电影推荐系统完全可以拆成独立的前端应用和后端服务，技术栈选择也很多样，但Spring Boot在这类毕设项目中几乎是“最不会翻车”的方案。

首要原因是生态成熟度。Spring Boot自带内嵌Tomcat，打出一个Jar包就能启动，不需要额外配置外部容器。配合Spring MVC可以快速把RESTful接口搭起来，配合MyBatis-Plus可以把数据访问层的开发效率拉满，最常用的场景基本不需要手写XML映射文件。对毕设作者来说，这意味着从项目创建到跑通第一个接口，往往只需要半天时间。

第二个原因是答辩时的解释成本低。Spring Boot的请求处理流程、依赖注入、事务管理这些基础概念，几乎是所有评委老师都熟的东西。你在答辩时讲“我用Spring Boot的拦截器做了登录校验”，老师一听就明白；讲“通过AOP统一记录用户行为日志”，这又是一个天然的加分点。说白了，选一个所有人都听得懂的技术栈，比选一个冷门但高深的技术栈，更容易在有限时间内拿到高分。

第三个原因是社区资料极其丰富。无论你在项目里碰到跨域问题、数据源配置问题，还是MyBatis-Plus分页失效的问题，搜索引擎一搜就有大量真实案例。我在这套系统的开发过程中遇到的大部分Bug，基本都能在某技术社区找到原样报错信息。这对应届生来说，等于背后站了一排免费导师。

提示：如果你选择的毕设方向对算法权重有更高要求，可以在Spring Boot基础上引入Python微服务做推荐计算，但那样会引入跨语言调用和部署复杂度。绝大多数情况下，纯Java实现推荐算法已经足够应付本科毕设的深度和演示效果。

2. 数据模型与数据库设计

2.1 六张核心表的字段规划

数据库是这个系统的基础，字段设计的合理程度直接决定了后面编码是顺手还是折磨。我在设计这套系统时，最终保留了六张核心业务表，另外通过一对多、多对多的关系把用户行为串起来。

用户表user是最基础的一张表，字段包括id、username、password、nickname、avatar、role、status、create_time。password字段需要强调一点，虽然很多毕设代码直接存明文，但从工程规范出发，至少也应该用MD5做一次散列。更好的做法是加盐加哈希，考虑到毕设演示和代码可读性，我会在注册接口里用Spring自带的DigestUtils做MD5加密。role字段用0表示普通用户，1表示管理员，方便后续在拦截器中做权限区分。

电影表movie的字段相对更多：id、title、director、actors、type_ids、region、release_date、duration、score、description、cover_url、status、create_time。这里有一个取舍问题：type_ids字段我直接用逗号分隔存储，比如“1,3,5”，而不是单独建一张电影-类型关联表。原因在于推荐算法需要快速读取电影类型特征，冗余存储让索引和计算都更直接，虽然牺牲了一点第三范式，但对于毕设项目来说这是合理的空间换时间策略。

评分表rating是推荐算法的数据基础，字段包括id、user_id、movie_id、score、create_time。score的取值范围明确限定在1到5之间，在接口层做参数校验。另一张评论表comment则包含id、user_id、movie_id、content、create_time，主要用于前台详情页的评论展示，也能在答辩时体现“社区氛围”这个点。

2.2 外键关系与查询效率取舍

理论上，rating表和comment表都该对user_id、movie_id建立外键约束，保证引用完整性。但在实际开发里，我建议逻辑外键优先，物理外键可选。原因很简单：MyBatis-Plus做多表关联时通常用业务方法控制，不依赖数据库级外键，遇到海量数据时外键校验还会拖慢写入速度。对于毕设尺度，逻辑外键完全够用，还能避免删除时外键约束干扰测试数据的清理。

建立索引是另一个关键。user_id和movie_id在rating表里应该建立联合索引，因为推荐算法最高频的操作就是“查某用户评过哪些电影”，以及“查某电影被哪些用户评分过”。comment表同理，按movie_id建立索引，支撑详情页的分页评论查询。

为了在代码里方便组装数据，我额外建了一个视图模型MovieVO。它不映射数据库表，而是把movie表字段、当前用户对该电影的评分、该电影的平均分和评论数封装在一个对象里，每次API返回给前端时直接序列化成JSON。这种“基础实体+辅助VO”的组合，是后期迭代时最省心的一种结构。

实操心得：在设计字段时把“推荐算法需要读哪些数据”想清楚，比先把CRUD跑通更重要。如果等到算法阶段再回去改表结构，涉及的Controller、Service、Mapper全要跟着改，那才是真正的折磨。

3. 推荐引擎：核心算法与工程落地

3.1 基于用户的协同过滤实现

推荐算法是整个系统的灵魂，这里我用的是“基于用户的协同过滤”，简称UserCF。它的核心思想很朴素：如果用户A和用户B在历史行为上高度相似，那么A喜欢的电影，B大概率也会喜欢。

具体到实现，分成三步。

第一步，构建“用户-电影”评分矩阵。等价地，我用一个Map<Long, Map<Long, Double>>来模拟二维矩阵，外层key是userId，内层key是movieId，value是对应的评分。

java复制public class RatingMatrix {
    private Map<Long, Map<Long, Double>> matrix = new HashMap<>();

    public void addRating(Long userId, Long movieId, Double score) {
        matrix.computeIfAbsent(userId, k -> new HashMap<>()).put(movieId, score);
    }

    public Map<Long, Double> getUserRating(Long userId) {
        return matrix.getOrDefault(userId, new HashMap<>());
    }
}

第二步，计算用户之间的相似度。相似度指标我选择了皮尔逊相关系数，而不是余弦相似度，原因是皮尔逊系数会先减去用户的平均评分，能消除用户“手松”或者“手紧”带来的系统性偏差。比如A习惯给高分，B习惯给低分，如果直接用余弦相似度，两人的相似度会被拉低；但皮尔逊系数先把各自的评分中心化，再比较形状，就更能反映真实的兴趣吻合度。

java复制public double pearsonSimilarity(Map<Long, Double> userA, Map<Long, Double> userB) {
    Set<Long> common = new HashSet<>(userA.keySet());
    common.retainAll(userB.keySet());
    if (common.size() < 2) {
        return 0.0;
    }
    double sumA = 0, sumB = 0;
    for (Long movieId : common) {
        sumA += userA.get(movieId);
        sumB += userB.get(movieId);
    }
    double avgA = sumA / common.size();
    double avgB = sumB / common.size();
    double numerator = 0, denomA = 0, denomB = 0;
    for (Long movieId : common) {
        double diffA = userA.get(movieId) - avgA;
        double diffB = userB.get(movieId) - avgB;
        numerator += diffA * diffB;
        denomA += diffA * diffA;
        denomB += diffB * diffB;
    }
    if (denomA == 0 || denomB == 0) {
        return 0.0;
    }
    return numerator / (Math.sqrt(denomA) * Math.sqrt(denomB));
}

第三步，寻找目标用户的K个最近邻，然后对目标用户未评分的电影做加权评分预测。权重就是用户间的皮尔逊相似度。公式可以记为：

预测评分 = 目标用户自身平均分 + (Σ(相似度 × (邻居对该电影评分 - 邻居自身平均分))) / Σ相似度

这样写的好处是保留了皮尔逊系数中心化带来的自然解释。最终把预测评分最高的前N部电影返回，就是推荐列表。

3.2 基于内容推荐的补充策略

UserCF有一个天然痛点：新用户没有评分记录，根本找不到相似用户。这个冷启动问题不能靠协同过滤硬解，所以我还实现了基于内容的推荐作为兜底。

基于内容的思路也很直接：把电影的类型、导演、主演转化为特征向量，然后计算电影之间的余弦相似度。系统第一次给用户推荐时，会先问用户“喜欢哪些类型”，或者默认推荐高分电影，等用户产生了行为后再平滑过渡到协同过滤。

我这里做了一个简化实现：每部电影维护一个关键词标签串，由类型、导演、主演拼接而成。用字符串分词后构造一个Map<String, Integer>词频向量，再用余弦相似度公式计算两两距离。

java复制public double cosineSimilarity(Map<String, Integer> vectorA, Map<String, Integer> vectorB) {
    Set<String> keys = new HashSet<>(vectorA.keySet());
    keys.retainAll(vectorB.keySet());
    double dotProduct = 0;
    for (String key : keys) {
        dotProduct += vectorA.get(key) * vectorB.get(key);
    }
    double normA = vectorA.values().stream().mapToDouble(v -> v * v).sum();
    double normB = vectorB.values().stream().mapToDouble(v -> v * v).sum();
    if (normA == 0 || normB == 0) {
        return 0.0;
    }
    return dotProduct / (Math.sqrt(normA) * Math.sqrt(normB));
}

实际应用时，先选一部用户最近高分评价的电影，计算它和所有其他电影的相似度，取TopN作为推荐结果，效果很直观。在演示阶段，你也可以直接指定一部种子电影，比如用户刚看完《流浪地球2》，系统就会推荐特征相近的科学类影片，答辩现场效果非常好。

3.3 推荐的冷启动问题怎么破

冷启动是推荐系统绕不开的话题，也是答辩老师最常追问的地方。我在这个项目里做了三层策略：

第一层，新用户注册后还没有任何评分行为时，推荐接口直接走“热门电影榜”。热门榜的排序公式是一个简单的加权评分，我把它设计为：

热门分 = 平均分 × 0.7 + 评分人数转化系数 × 0.3

评分人数转化系数用“该电影评分人数 / 全站最大评分人数”来计算，目的是让一部只有两个人打满分的小众电影不至于排在三千人评分的口碑大片前面。

第二层，用户有至少一次评分行为后，进入基于内容的推荐阶段。我根据用户最近一次高分评价的电影ID，计算出与之最相似的10部电影，再过滤掉已经看过的。

第三层，用户评分数量达到5条以上，才切到基于用户的协同过滤。因为评分数据太少的话，计算出来的相似度矩阵非常稀疏，邻居质量很差，推荐结果随机性大，不如内容推荐稳定。

这三层策略在代码里对应一个简单的路由逻辑，每次调用推荐接口时先判断条件再选择算法，逻辑清楚，答辩讲解也容易。

实操心得：不要把协同过滤算法的逻辑线拉得太长。很多同学喜欢一上来就写复杂的矩阵分解、SVD，最后自己都被绕晕了。毕设项目的核心是把推荐逻辑讲明白、演示效果好，UserCF加内容冷启动已经足够撑起技术深度了。

4. 业务功能与接口实现细节

4.1 用户注册与登录

用户模块是系统安全性的第一道门，也是答辩时最容易演示的功能。注册接口接收username、password、nickname，后端先查重，再对密码做MD5散列，最后落库。返回给前端的时候，密码字段要置空，避免在返回JSON中暴露。

登录接口则做成JWT无状态认证。用户携带用户名密码请求成功后，后端签发一个有效期为7天的token，返回给前端。后续每次请求都需要在Header中携带这个token，后端拦截器会解码并校验。

核心的拦截器实现大致是这样：

java复制public class JwtInterceptor implements HandlerInterceptor {
    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        if ("OPTIONS".equalsIgnoreCase(request.getMethod())) {
            return true;
        }
        String token = request.getHeader("Authorization");
        if (token == null || !JwtUtil.validateToken(token)) {
            response.setStatus(401);
            return false;
        }
        Long userId = JwtUtil.getUserId(token);
        request.setAttribute("currentUserId", userId);
        return true;
    }
}

这里的细节是，前端在跨域预检请求OPTIONS时必须放行，否则浏览器会在正式请求前拦截掉。这个坑很多人都会踩，后面我会在第七节展开讲。

4.2 电影的增删改查与榜单聚合

电影模块的CRUD是后端的骨架，但这里有两个和普通管理系统不一样的接口设计值得说一下。

第一个是分页列表接口。它不仅仅是简单的limit查询，还需要带上类型筛选、关键词模糊搜索、排序字段参数。我用MyBatis-Plus的分页插件完成，调用Page对象传入页码和页大小，再用LambdaQueryWrapper构建条件。为了支持评分从高到低排序，movie表的score字段在每次有新的评分产生时，用一条Update语句统一重算。

第二个是首页聚合接口。前端首页需要同时展示“热门榜单”“最新影片”“推荐列表”三块内容，如果在Controller里分别调三次Mapper那也能跑，但会产生多次连接往返。我建议在Service层做一个聚合方法，一次请求内并行查询或顺序组装后返回一个Map<String, Object>，前端只需要调用一次首页接口就能拿全所有板块的初始数据。

4.3 评分、评论与收藏

评分功能看似简单，但有一个隐藏逻辑很容易被忽略：同一用户对同一部电影只能保存最新的一条评分。这意味着评分接口必须先查rating表中是否已有记录，有则走更新，无则走新增。同时在评分写入后，需要实时更新对应movie表的score和评分人数。

我用了事务注解来保障一致性：

java复制@Transactional(rollbackFor = Exception.class)
public Result<?> submitRating(Long userId, Long movieId, Integer score) {
    Rating rating = ratingMapper.findByUserIdAndMovieId(userId, movieId);
    if (rating != null) {
        rating.setScore(score);
        ratingMapper.updateById(rating);
    } else {
        Rating newRating = new Rating();
        newRating.setUserId(userId);
        newRating.setMovieId(movieId);
        newRating.setScore(score);
        ratingMapper.insert(newRating);
    }
    updateMovieScore(movieId);
    return Result.success();
}

评论接口则要处理内容安全基础校验，比如空内容、长度限制。收藏功能相对独立，一条收藏记录包含用户ID和电影ID，查询时返回该用户收藏的影片列表。

注意事项：任何涉及写操作的接口，都建议加上@Transactional事务注解，避免评分写入成功但电影平均分更新失败时出现数据不一致。答辩时老师如果追问“你的系统怎么保证数据一致性”，这句话能直接得分。

5. 部署运行与踩坑实录

5.1 环境准备与配置文件

这套系统依赖的基础环境是三件套：JDK 1.8及以上、MySQL 5.7或8.0、Maven 3.6及以上。如果你愿意再装一个Node环境，前端预览效果会更完整，但本次核心后端只要装前三样就能跑起来。

数据库初始化时，我提前准备了一个schema.sql脚本，里面包含了建库建表语句，还有一个data.sql脚本填入了大约60部电影测试数据和一批模拟观众的评分数据。没有这批测试数据，推荐算法跑出来的结果会是空的或随机的，演示效果直接归零。

项目核心配置在application.yml中，必须确认的地方有三个：数据库地址、账号密码、时区设置。

yaml复制server:
  port: 8080

spring:
  datasource:
    url: jdbc:mysql://localhost:3306/movie_recommend?useUnicode=true&characterEncoding=utf-8&serverTimezone=Asia/Shanghai
    username: root
    password: 123456
    driver-class-name: com.mysql.cj.jdbc.Driver

mybatis-plus:
  mapper-locations: classpath*:mapper/*.xml
  type-aliases-package: com.movie.recommend.entity
  configuration:
    log-impl: org.apache.ibatis.logging.stdout.StdOutImpl

需要注意的是，如果本地MySQL是5.x版本，驱动类名要把com.mysql.cj.jdbc.Driver换成com.mysql.jdbc.Driver，这个变化是驱动版本历史演进来的，容易踩坑。

5.2 启动项目的完整步骤

从零到跑通这套系统，正常步骤是：先创建数据库并导入schema.sql和data.sql，再用IDEA打开后端源码文件夹，等待Maven把依赖下载完成。这里Maven耗时取决于网络环境，如果第一次下载比较慢，建议配置国内镜像源，否则可能等得人焦虑。

依赖就绪后，在Run Configuration中选择主启动类，点击运行。看到控制台出现Tomcat started on port 8080字样，就说明后端成功起来。接着用浏览器访问Swagger地址或直接用Postman调用接口。

如果是部署到服务器上，可以跳过IDEA，直接执行Maven打包命令：

bash复制mvn clean package -DskipTests
java -jar target/movie-recommend-0.0.1-SNAPSHOT.jar

打包产出的Jar包自带内嵌Tomcat，放到任意有JDK环境的服务器上就能运行，这点就是Spring Boot最大的部署优势。

5.3 常见问题与排查方向

我在开发和调试这套系统的过程中，收集了一批大家最容易撞上的问题，整理成一张速查表。

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

配好之后，前后端分离开发时几乎不会再被跨域问题卡住。生产环境如果更在意安全性，可以把allowedOriginPatterns换成前端实际域名，原理不变。

6. 推荐结果的评测与可视化体验

推荐系统做了出来，怎么向答辩老师证明它有效，也是一项需要提前准备的功课。我在这套系统里补充了三个可演示的效果维度。

第一个维度是推荐列表的命中验证。找一个测试用户账号，查看这个用户的历史高分电影，再看系统推荐给他的电影，如果推荐list里有风格相近的作品，可以直接把前后两部电影的相似度数值摆出来展示。比如用户给某部科幻高分，推荐的Top3也是科幻，这就是基于内容策略在起作用。

第二个维度是热门榜与个性化推荐的对比。当用户评分数量很少的时候，推荐结果会偏向热门；当评分变多之后，推荐结果开始脱离大众榜单，出现一些小众但风格匹配的影片。这个“从通用到个性化”的转变，在答辩现场可以成为一个小亮点。

第三个维度是接口响应速度。推荐算法虽然要遍历用户评分矩阵，但在几千条评分数据规模下，计算耗时通常不会超过200毫秒，不会让用户感到卡顿。这里如果发现响应超时，一般不是算法太慢，而是在Service层循环里频繁调用Mapper查询导致连接开销过大，优化方向是提前把评分数据一次性load到内存里再做矩阵计算。

实操心得：保证推荐接口稳定运行的同时，我建议把日志级别调成DEBUG跑一次全流程，观察SQL执行次数。如果发现N+1查询问题，比如循环里每次都查一次电影信息，尽量改成批量查询IN一次拿回所有数据，性能会明显提升。

7. 源码阅读与二次开发建议

如果拿到的这套毕设源码是一个完整工程，最忌讳的事情是直接拿过来就改学生信息然后提交。真正有价值的做法，是把代码按“启动配置-数据层-业务层-接口层-算法层”的层次读一遍，标记出关键类。

我推荐一个实用的阅读顺序：先打开pom.xml看依赖列表，理解项目用了哪些组件；再看application.yml了解运行环境；然后从controller包入手，看暴露了哪些接口；接着看service包，理解业务逻辑和数据组装方式；最后重点看recommend包下的算法实现，这里通常也是答辩时最容易被提问的地方。

二次开发的话，我列几个低成本但效果明显的扩展方向。第一个是把本地的评分矩阵换成Redis缓存，提升推荐接口的实时性能，这是一个加分点。第二个是为推荐算法增加一个时间衰减因子，让最近的行为比更早的行为权重更大，推荐结果会更“跟手”。第三个是增加一个简单的推荐理由模块，比如在每部推荐电影后面标注“因为你评过《某影片》”，这能显著提升用户体验，实现门槛却不高。

这些扩展的复杂度都在可控范围内，适合在毕设答辩前的一到两周内，挑一个方向集中完成。

8. 这套系统后续还可以怎么玩

最后还是想多说一句和项目源码无关、但和个人成长有关的事。很多人拿到这类系统的源码，第一反应是把标题改成自己的名字，然后草草提交。但如果你愿意多花一个周末，把推荐算法从“能跑通”到“背理解透”，从“会调用”到“能改参数”，答辩时你能讲出来的内容完全是两个档次。

我建议你在跑通系统之后，主动做一件事：把一个用户的评分数据人为清空，然后用这个账号请求推荐，观察推荐结果是怎样回落到热门榜的。再去另一个评分较多的账号看推荐列表，对比个性化差异。亲手在真实数据上验证推荐链路的前后逻辑，比看一百遍原理讲解都要管用。

根据我个人的经验，电影推荐系统这种“经典但不过时”的毕设题，真正的技术门槛不在于用多新的框架，而在于你有没有把推荐算法的输入输出模型理清楚、把用户行为到推荐结果的数据闭环走通。这一步做扎实了，整个工程就是一套非常完整的、可展示的、有说服力的作品。后面无论是继续做毕设深化，还是拿这套代码去丰富个人项目集，都是顺理成章的事。