Java Web电影推荐系统实战：Spring Boot + 协同过滤算法实现

简介：基于SSM（Spring+SpringMVC+MyBatis）与Vue开发的电影推荐系统Java Web项目源码，适用于毕业设计、课程设计或SSM整合实战练习。资源共845个文件，压缩包大小17.62MB，涵盖Java后端源码、Vue前端页面、JavaScript/CSS等静态资源、MySQL数据库脚本、Maven及项目配置文件，并附有一键环境搭建与启动脚本，便于快速导入运行。系统采用B/S架构，数据库使用MySQL 5.7，前端采用ElementUI，实现了用户信息、图片素材、视频素材等模块，代码注释清晰、目录结构规范，完整呈现从需求分析到系统实现的SSM开发流程，可帮助读者理解前后端数据交互、MyBatis持久化配置及SpringMVC请求路由等关键环节。已有282人浏览学习，适合具备一定Java基础的开发者参考借鉴。

1. 电影推荐系统源码：先搞清楚它解决什么问题，再决定要不要动手

如果你是在毕业设计、课程设计或跳槽作品集里搜到“电影推荐系统”这几个字，那大概率已经不是第一次看到类似题目了。这个方向每年都有大量 Java 方向的 Web 项目在做，原因很直接：它有完整的业务闭环——用户、电影、评分、推荐、后台管理，既能展示 Java 后端基本功，又能讲出“推荐算法”这个亮点，比纯增删改查的管理系统更容易在答辩时撑起场面。

但这里要先泼一盆冷水：标题里同时出现“推荐系统源码”“管理系统”“设计与实现”，意味着这类项目通常不是一个工业级的推荐平台，而是一个能跑通、能演示、能讲清楚原理的 Java Web 应用。核心价值不在算法多先进，而在于三层东西：数据模型设计是否合理（用户-电影-评分怎么建表）、协同过滤逻辑是否讲得通、以及后台管理有没有覆盖电影和用户的完整操作闭环。

这篇文章我会按这套逻辑，把基于 Web 的电影推荐系统怎么做讲透。顺序是：先定技术栈和架构，再给库表设计和实体映射，然后落到推荐算法的 Java 实现，最后把部署阶段最容易翻车的几个问题先指出来。读者里如果是 Java 基础一般、第一次做完整 Web 项目的，照着这条线走一遍，能少走很多弯路；如果已经写过几个管理系统，重点看第四章的协同过滤实现和第五章的边界问题，那部分才是这个题目真正拉开差距的地方。

2. 技术选型与整体架构：Spring Boot 为主干的三层结构，为什么这么搭

2.1 后端框架选型：Spring Boot 是这类题目的默认答案，但不是唯一答案

电影推荐系统在 Java 技术栈里最常见的搭配是 Spring Boot + MyBatis/Spring Data JPA + MySQL + Thymeleaf（或前后端分离）。Spring Boot 之所以成为默认答案，不是因为它在推荐算法上有什么特殊优势，而是因为它把 Web 层、数据访问层、事务管理、内置 Tomcat 全部打包好了，你在答辩时可以花更多时间讲推荐逻辑，而不是纠结怎么配置 web.xml。

如果只用标题“基于 Web 的 Java 电影推荐系统”来推断，更常见的课程设计是服务端渲染方案：Spring Boot 提供接口和页面渲染，Thymeleaf 直接输出 HTML。这个选择的优点是对新手友好，不需要处理跨域、不需要单独部署前端工程，一个mvn spring-boot:run就能看到完整效果。前后端分离（Spring Boot + Vue）的版本更多出现在近两年的题目里，但如果你对 JavaScript 不熟，强行上 Vue 反而会增加工作量。

我一般建议按下面的标准来判断选型方向：

如果目标是把系统跑通并讲清楚，选 Thymeleaf 方案就够了，这也是我从实践里更推荐的方式。而数据库访问层，JPA 在实体关系映射上写起来更短，MyBatis 则在复杂 SQL 上更可控。电影推荐系统的 SQL 复杂度不高，两者都可以。下面的示例以 Spring Data JPA 为主，因为它能让实体代码短很多。

2.2 架构分层与三张核心表的关系：用户、电影、评分是推荐系统的地基

整个系统我习惯拆成四个包：controller、service、repository、entity，对应表现层、业务层、数据访问层和实体层。推荐的灵魂在service包里，不只是在 controller 里写几行 SQL。

核心数据关系只有三张表：用户表（user）、电影表（movie）、评分表（rating）。用户通过评分与电影建立联系，推荐算法就是基于这张评分表计算“相似的人”或“相似的电影”。

-- 用户表 CREATE TABLE `user` ( `id` bigint NOT NULL AUTO_INCREMENT, `username` varchar(50) NOT NULL, `password` varchar(100) NOT NULL, -- 建议存 BCrypt 加密后的结果 `created_at` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 电影表 CREATE TABLE `movie` ( `id` bigint NOT NULL AUTO_INCREMENT, `title` varchar(200) NOT NULL, `genre` varchar(100) DEFAULT NULL, `release_year` int DEFAULT NULL, `director` varchar(100) DEFAULT NULL, `poster_url` varchar(500) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 评分表 CREATE TABLE `rating` ( `id` bigint NOT NULL AUTO_INCREMENT, `user_id` bigint NOT NULL, `movie_id` bigint NOT NULL, `score` tinyint NOT NULL COMMENT '1-5分', `rated_at` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_user_movie` (`user_id`, `movie_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

三个表之间有两个关键设计点。第一，评分表上加唯一索引uk_user_movie，避免同一个用户对同一部电影重复评分，这是推荐数据干净的基本保证；如果漏掉这个约束，后面算用户相似度时会出现重复计数，推荐结果直接失真。第二，用户密码不能明文存储，这是这类系统经常被点评的细节，建议在注册时用BCryptPasswordEncoder加密，答辩时这是可以主动讲出来的加分点。

还有一张表在实现“电影推荐管理系统”时不可或缺：favorite收藏表。它记录用户主动收藏的电影，一方面可以丰富推荐入口，另一方面在前端“我的收藏”页面直接展示。核心逻辑是用户对电影的显式反馈有三种：评分、收藏、浏览记录。评分和收藏用于推荐算法的输入，浏览记录则可以在“最近浏览”功能中展示，形成完整的数据采集闭环。

2.3 数据从哪来：爬取豆瓣 Top250 作为填充数据的常规方案

库表建好之后，不能空着跑推荐。电影推荐系统需要真实的电影数据，否则推荐结果毫无说服力。常见做法是解析豆瓣电影 Top250 并入库。但这里要建议你：不要花太多时间在数据采集上。Top250 一共 250 条，包含电影名、导演、类型、年份、评分、简介，足够完成演示和测试推荐效果。

我一般用 HttpClient 或 Jsoup 抓取，存成 SQL 脚本直接导入，而不是在代码里做实时爬虫。抓取时要注意两个细节：一是类型字段用英文逗号分隔，方便后面做“同类电影”推荐；二是把海报 URL 一并存下来，前端页面会好看很多。抓取数据属于一次性工程，不用做得太复杂，代码里留一个data.sql文件即可，让系统启动时自动初始化数据，省去手工导入的步骤。

这块的典型问题是很多同学直接从网上下载了一个 movie.sql，但表结构和字段名对不上，改起来反而更耗时。最稳妥的方式是理解实体类的字段顺序，然后保证 SQL 的插入列名和实体类的@Column名称一致。

3. 从建库到跑通接口：实体类设计与用户评分闭环的实现

3.1 用 JPA 注解定义实体：Movie 与 Rating 的映射关系

上一章给出的建表 SQL，现在需要落到 Java 实体上。以 Movie 表为例，字段映射如下：

@Entity @Table(name = "movie") public class Movie { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private Long id; @Column(nullable = false, length = 200) private String title; @Column(length = 100) private String genre; @Column(name = "release_year") private Integer releaseYear; private String director; @Column(name = "poster_url", length = 500) private String posterUrl; // getter / setter / 构造函数略，实际开发中用 Lombok @Data 简化 }

这里的@Column(name = "release_year")必须和表字段名严格一致，否则 JPA 启动时不会报错，但查询结果里 releaseYear 始终为 null。这是 Spring Data JPA 新手经常碰到的问题。如果用 Lombok，只需要在类上加@Data注解，getter/setter 自动生成，代码能少一半。

接着是 User 和 Rating 实体。Rating 实体不直接用@ManyToOne关联对象，而是只存userId和movieId两个 Long 字段。原因是推荐算法要批量遍历所有评分，关联对象会导致大量延迟加载。为了性能，实体设计上做“扁平化”，关联关系在 Service 层手动拼接。

@Entity @Table(name = "rating", uniqueConstraints = { @UniqueConstraint(columnNames = {"userId", "movieId"}) }) public class Rating { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private Long id; @Column(name = "user_id", nullable = false) private Long userId; @Column(name = "movie_id", nullable = false) private Long movieId; @Column(nullable = false) private Integer score; // 1-5 @Column(name = "rated_at") private LocalDateTime ratedAt; }

注意 JPA 列名默认的驼峰转下划线策略。userId字段默认映射到user_id，如果你在application.yml里关闭了spring.jpa.hibernate.naming.physical-strategy的默认配置，就可能在运行时报“列 userId 不存在”。为了保险，上面代码里显式标注了@Column(name = "user_id")。这里全都是经得起运行验证的细节，写的时候一步到位能省下很多调试时间。

3.2 用户注册登录与评分接口：写推荐系统之前先建立数据采样入口

推荐系统的效果取决于评分数据的数量和质量。所以第一步不是实现推荐算法，而是先把用户评分接口写出来。一个完整的评分闭环包括：用户注册登录 → 浏览电影列表 → 点击某部电影 → 评分 → 刷新后看到评分状态。

接口设计遵循 REST 风格即可：

@PostMapping("/api/rating") public Result rateMovie(@RequestBody RateRequest request) { Rating rating = ratingService.rate(request.getUserId(), request.getMovieId(), request.getScore()); return Result.success(rating); } @GetMapping("/api/movie/{id}") public MovieVO getMovieDetail(@PathVariable Long id) { Movie movie = movieService.findById(id); List<RatingVO> ratings = ratingService.findByMovieId(id); return MovieVO.from(movie, ratings); }

ratingService.rate里的核心逻辑是“存在则更新，不存在则插入”。用上一章那张唯一索引，可以先findByUserIdAndMovieId，有记录就更新 score，没有就新建。这个逻辑虽然简单，却决定了推荐算法候选集的质量。另外，管理员后台能够批量导入评分数据，比如给新注册用户随机生成 10 条评分，这样在演示协同过滤时不需要手工一条条去点，效果展示更快。

评分接口完成后，推荐系统的数据基础就搭好了。下一步才进入重头戏：什么样的算法能让一个只有几百条评分的数据集跑出“像样”的推荐列表。

4. 协同过滤推荐算法：用基于用户的 UserCF 撑起“推荐”两个字

4.1 为什么选 UserCF 而不是 ItemCF：从数据规模和答辩角度分析

推荐算法主流分为基于内容的推荐和协同过滤推荐。协同过滤又分成基于用户的（UserCF）、基于物品的（ItemCF）和基于模型的（矩阵分解等）。对电影推荐这种规模的 Web 项目，基于物品的推荐在工业界如 Amazon 中表现优秀，但课程设计里我更推荐 UserCF。

原因有两个。第一，数据规模小。UserCF 的原理是“找到和你口味相似的用户，把那些用户喜欢而你没看过的电影推荐给你”。评分表只有几百行，计算相似度时时延完全可以接受；如果换 ItemCF 要计算电影间的相似度矩阵，效果差异在数据量大时才能体现，而演示场景下 UserCF 更好讲。第二，UserCF 的另一方面优势是推荐结果更有“故事性”——“和你兴趣相似的用户也在看《霸王别姬》”，这句话在答辩时可以直接讲给评委听，容易让思路被理解。

4.2 UserCF 的完整 Java 实现：相似度矩阵、TopK 邻居与推荐列表生成

下面是一段可以直接放到项目里的核心代码。它包含三个步骤：第一步计算用户相似度矩阵；第二步为指定用户找到 TopK 最相似用户；第三步为目标用户生成推荐列表。

@Service public class RecommendService { @Autowired private RatingRepository ratingRepository; @Autowired private MovieRepository movieRepository; // 1. 构建用户->电影评分的映射 private Map<Long, Map<Long, Integer>> buildUserRatingMap() { List<Rating> allRatings = ratingRepository.findAll(); Map<Long, Map<Long, Integer>> userRatings = new HashMap<>(); for (Rating r : allRatings) { userRatings .computeIfAbsent(r.getUserId(), k -> new HashMap<>()) .put(r.getMovieId(), r.getScore()); } return userRatings; } // 2. 计算两个用户之间的余弦相似度 private double cosineSimilarity(Map<Long, Integer> u1, Map<Long, Integer> u2) { Set<Long> commonMovies = new HashSet<>(u1.keySet()); commonMovies.retainAll(u2.keySet()); if (commonMovies.isEmpty()) { return 0.0; } double dot = 0, norm1 = 0, norm2 = 0; for (Long movieId : commonMovies) { dot += u1.get(movieId) * u2.get(movieId); } for (Integer score : u1.values()) { norm1 += score * score; } for (Integer score : u2.values()) { norm2 += score * score; } if (norm1 == 0 || norm2 == 0) { return 0.0; } return dot / (Math.sqrt(norm1) * Math.sqrt(norm2)); } // 3. 为目标用户生成 TopN 推荐 public List<Movie> recommendForUser(Long userId, int topN) { Map<Long, Map<Long, Integer>> userRatings = buildUserRatingMap(); Map<Long, Integer> targetUserRatings = userRatings.getOrDefault(userId, Collections.emptyMap()); // 计算目标用户与所有其他用户的相似度 Map<Long, Double> similarityScores = new HashMap<>(); for (Map.Entry<Long, Map<Long, Integer>> entry : userRatings.entrySet()) { if (entry.getKey().equals(userId)) continue; similarityScores.put(entry.getKey(), cosineSimilarity(targetUserRatings, entry.getValue())); } // 按相似度排序，取 TopK 邻居 List<Map.Entry<Long, Double>> sorted = new ArrayList<>(similarityScores.entrySet()); sorted.sort((a, b) -> Double.compare(b.getValue(), a.getValue())); List<Map.Entry<Long, Double>> topK = sorted.subList(0, Math.min(5, sorted.size())); // 从邻居的评分中收集候选电影，按加权分数累加 Map<Long, Double> candidateScores = new HashMap<>(); Map<Long, Integer> candidateCount = new HashMap<>(); for (Map.Entry<Long, Double> neighbor : topK) { if (neighbor.getValue() <= 0) continue; Map<Long, Integer> neighborRatings = userRatings.get(neighbor.getKey()); for (Map.Entry<Long, Integer> movieRating : neighborRatings.entrySet()) { Long movieId = movieRating.getKey(); if (targetUserRatings.containsKey(movieId)) { continue; // 过滤掉已评分的电影 } candidateScores.merge(movieId, neighbor.getValue() * movieRating.getValue(), Double::sum); candidateCount.merge(movieId, 1, Integer::sum); } } // 按加权分数排序，取 TopN 返回 List<Map.Entry<Long, Double>> ranked = new ArrayList<>(candidateScores.entrySet()); ranked.sort((a, b) -> Double.compare(b.getValue(), a.getValue())); List<Long> movieIds = ranked.stream() .limit(topN) .map(Map.Entry::getKey) .collect(Collectors.toList()); return movieRepository.findAllById(movieIds); } }

这段代码有几个参数值得说明。cosineSimilarity里的余弦相似度是核心，公式是共同评分电影的点积 / 两个用户评分向量的模长的乘积。共同评分数为 0 时直接返回 0，避免除零异常。topK选择了 5，当用户数量较少时这个值足够；如果测试账号打分到几百条，可以适当加大到 10。候选电影分数累加时用了merge,相当于对邻居相似度和评分的乘积求和，比单纯“评分平均值”更能体现出相似度权重。

从实际运行角度看，这段代码在评分数据几千条时性能没有问题，因为buildUserRatingMap()一次把所有评分读进内存，后续计算全在内存完成。但从代码严谨性出发，还有一个可以优化的小点：recommendForUser每次请求都会重新计算全局相似度，这不算高效，却在课程设计代码里很常见。只需在答辩时说明“下一步可以改成离线预计算”，就不会被挑战。

4.3 冷启动处理：当用户没有评分时，按热度推荐打底

如果数据库里只有一个测试用户，或者用户首次注册还没有任何评分，协同过滤无数据可用。此时推荐列表自然为空，页面会很难看，会显得项目没完成。

解决手段用“默认推荐”兜底即可。当targetUserRatings.size() == 0或相似度 TopK 全部为 0 时，直接返回热度最高的电影，热度按评分数量和平均分综合排序。下面是简单的实现思路：

@Query("SELECT r.movieId, COUNT(r.id) AS cnt, AVG(r.score) AS avgScore " + "FROM Rating r GROUP BY r.movieId " + "ORDER BY cnt DESC, avgScore DESC") List<Object[]> findHotMovies();

热度榜是推荐系统冷启动的标准方案，把它放在用户协同过滤之前作为兜底，能让新用户第一次打开首页就有内容看。这个细节在演示环节几乎一定会被问到，主动讲“冷启动阶段我们用热度榜兜底，积累评分后自动切换协同过滤”，这体现的就是设计意识。

5. 部署与运行阶段的五个高频坑：从推荐为空到登录失效的血泪经验

5.1 冷启动导致推荐结果为空：页面白屏，接口返回空数组

这是一个出现频率非常高的现象。它发生在你刚注册完新用户，点进“为你推荐”页面时，接口返回[]，页面上什么都没有。原因就是上一章讲的协同过滤的前置条件不成立——用户没有评分数据，算法无法计算相似用户，推荐候选集自然是空的。

处理方法就是上一章的“热度榜兜底”recommendForUser方法开头加判断：如果该用户的评分数量为 0，直接调用电影热度榜接口返回。这里是逻辑分支，不是异常处理，更需要的是提前想到这个场景。另外，管理后台里增加“为测试用户生成随机评分”的功能，也是演示前准备的一个技巧，一键生成 10 条评分再刷新推荐页，效果直观。

5.2 新加的依赖在启动时直接报错：JPA 实体类映射不匹配

有次我在自己电脑上跑一个网上拿到的现成工程，启动时 Spring 报Caused by: org.hibernate.AnnotationException: No identifier specified for entity，一查原因，是实体类里没有@Id主键标注，或者主键字段名和表结构对不上。另一种常见情况是Column name "xxx" not found，原因多半是实体类的字段命名规则和数据库实际列名不一致。

处理方式分两类。自己从零写代码时，建表脚本和实体类要同时维护，写完表结构先跑一次spring.jpa.hibernate.ddl-auto=validate，让 Hibernate 在启动时帮你校验映射是否一致。从网上下载源码时，不要直接依赖别人的data.sql，先看实体类字段，再对照建表 SQL 统一列名。这个步骤能省下大量排查时间。

5.3 N+1 查询导致页面很慢：一次聚会页面发出上百条 SQL

推荐结果包含 10 部电影，页面每部电影要拉取评分和封面，日志里发现一次请求产生了 100 多条 SQL。这是典型的 N+1 问题：先查出电影列表，再逐条查电影的评分、导演等信息。在小数据集上问题不明显，但如果数据量到几千部电影，接口响应时间会从几十毫秒涨到好几秒。

解决方式是批量查询。查完movieIds列表后，用ratingRepository.findByMovieIdIn(movieIds)一次性查出所有评分，在 Java 内存里按movieId分组组装到 VO。这是推荐系统 Web 化之后逃不开的性能优化点。要让代码里养成“先批量取数，再内存组装”的习惯，而不是依赖 JPA 的懒加载去逐条 get。

5.4 跨浏览器页面样式错乱：推荐列表在新版 Chrome 正常，IE 上布局完全散掉

热词里反复出现“跨浏览器支持的设计与实现”，其实反映的就是这个高校项目答辩时的高频问题。用 Thymeleaf 加 Bootstrap 的老式页面，特别依赖 CSS 框架的版本兼容性。如果演示机器上的浏览器版本较旧，或者用了国产浏览器的兼容模式，页面布局会直接错乱。

解决思路不复杂：第一，模板里显式声明<meta charset="utf-8">，避免乱码；第二，不要在页面上大量使用最新的 CSS Grid 或 flex 新特性，Bootstrap 4/5 的栅格系统对旧浏览器相对友好；第三，演示前用 Chrome 的无痕模式跑一遍全部页面，避免旧缓存和插件干扰。这个坑听起来不算技术难题，但在答辩现场翻车的概率极高，属于“演示前一小时最容易让人崩溃”的那类问题。

5.5 登录状态突然失效：刷新页面就跳回登录页，推荐接口报 401

如果系统实现了登录拦截，这种问题的典型原因是 Session 持久化配置不对。Spring Boot 默认的 Session 存储在内存里，应用重启后所有登录态全部丢失。有的同学在本地开发时不觉得，但换到部署环境，或者演示前不小心重启了应用，就会发现所有页面都要重新登录。还有一个更隐蔽的原因——前后端分离模式下，前端没在请求头带上 Cookie，导致后端拿不到 Session。

常规做法是配置 Spring Session 把会话存到 Redis，但一个课程设计项目为此引入 Redis 显得偏重。我更推荐的方案是明确告知“本地演示时重启后需要重新登录”，同时在拦截器里把/api/login、/api/register和首页排除掉，保证即使 Session 失效也不至于影响演示流程。如果排查这类问题，先从浏览器开发者工具里看请求头是否带上了Cookie，再查后端拦截器是否误拦截了静态资源，这两步能覆盖掉大部分登录失效的场景。

6. 让答辩和演示经得起追问：推荐算法验证与演示细节设计

系统做完后，最容易被问倒的问题往往是“你这个推荐效果到底怎么样”。所以最后一章把验证手段和演示脚本的设计讲清楚。推荐效果验证不追求学术指标，但至少要能用数据说话。常见做法是把评分表按 8:2 切分训练集和测试集，再用训练集跑推荐，看测试集里用户真实看过的电影有多大比例出现在推荐列表里。配合下面这个伪代码思路做统计：

// 按用户划分：每个用户取 80% 的评分做训练，20% 做验证 // 训练集跑 recommendForUser，验证集统计命中率 double precision = hits / (double) topN;

不用把评估模块做得很重，一个能够输出“测试用户 12 的推荐命中率是 30%”的统计就够了。因为答辩评委不会深究你的召回率曲线，但会关注你有没有基本的验证意识。演示时我建议走一条固定的路径：先用管理员账号在后台给新用户生成 5～8 条高评分记录，比如全是科幻片，然后切换到用户端打开“为你推荐”，展示的结果里应该出现同类型的其他科幻电影。这时再补一句“这是基于用户相似度的协同过滤，系统找到了口味相近的用户”，整个过程自然流畅，突出核心价值。

另一个容易加分的小技巧是让用户先给《流浪地球》打 5 分、给《星际穿越》打 5 分、给一部爱情片打 1 分，刷新推荐页时注意力全放在“推荐里没有爱情片”这个点上——负反馈被过滤掉，证明算法不只是按热度推。这个演示细节会让评委觉得你的算法真实生效了，而不是拿了一个固定列表在糊弄。前端如果因为时效性没更新，记得在评分后调recommendForUser接口重新拉取，不要复用一个页面级缓存。

最后的经验之谈是关于代码里那些看起来不重要的分支。用到“用户没有评分就推热门榜”“用户已经看过的电影不进推荐列表”这两个判断，在答辩时价值不低于算法本身。它们证明你考虑了真实使用场景，而不是只在理论数据上跑通。我自己的习惯是给每个关键分支写一个注释，标明“没有评分时的兜底逻辑”，几个月后回看代码能快速回忆起设计意图。

这份方案如果照着一路做下来，从建库、评分、协同过滤到页面展示，是一个完整可演示的闭环，也是电影推荐系统这个题目下比较稳的落地路径。希望帮到你。

本文还有配套的精品资源，点击获取