简介这是一份基于Java SSM框架的电影推荐系统完整源码包面向高校计算机专业学生及初入行的Java开发者可用于毕业设计、课程设计或SSM整合实战练习。系统覆盖用户管理、图片与视频素材维护、推荐展示等核心模块并配有MySQL 5.7数据库脚本和Maven工程配置便于快速搭建运行环境。资源共845个文件包含128个Java后端类、49个Vue组件、167个JavaScript脚本以及HTML、CSS、XML、SQL等辅助文件压缩包大小17.62MB目录结构清晰。此外还附带项目设计文档docx和安装运行批处理脚本可对照源码理解B/S架构下Spring、SpringMVC、MyBatisPlus与前端Vue的整合思路。目前已有282人下载学习适合需要完整参考实现与动手调试的中级开发者。1. 选电影推荐系统做 Java Web 毕业设计SSM 源码项目一次讲清架构、算法和部署选电影推荐系统做 Java Web 方向的毕业设计或课程项目是风险很低的组合。这套基于 SSMSpring SpringMVC MyBatis的电影推荐系统源码把前台电影展示、用户注册登录、评分管理、后台管理以及基于用户协同过滤的推荐模块全部揉在一个能直接运行的项目里——不是只给你几个 CRUD 例子而是从登录页到推荐列表都完整打通。它能解决的核心问题很明确一是快速出一套「数据库设计 算法实现 Web 工程」齐全的毕业设计成果二是给想学 SSM 和推荐算法落地的 Java 开发者一份有业务逻辑的真实代码。适合三类人需要交付毕设的学生、想练手完整工程的 Java 新人、以及想搞懂协同过滤怎么从公式变成代码的开发者。下面按架构选型、数据表、推荐引擎、部署排错的顺序拆。2. 推荐算法选型为什么这套源码选 UserCF 而不是 ItemCF2.1 电影推荐场景选 UserCF 的三个理由先说结论这套源码用的是基于用户的协同过滤UserCF。算法思路一句话——找到和你口味最像的一批用户把他们看过且评分高的电影推荐给你。相比之下基于物品的协同过滤ItemCF是找“和你已经喜欢电影相似”的其他电影拿购物网站举例更直观买过《算法导论》的人大概率会买《编程珠玑》这就是 ItemCF。对比维度UserCFItemCF适用场景用户规模小于物品规模偏冷门内容挖掘物品数量稳定用户兴趣相对固定实时性用户行为变化感知慢物品相似度可离线算响应快可解释性“和你口味相似的人还喜欢”“因为你看过 XXX所以推荐 XXX”电影推荐系统为什么要选 UserCF三个现实理由。第一电影数量在毕设项目里通常是几百到一两千条用户量级也完全可控UserCF 的训练和实时计算成本扛得住第二电影是重内容消费用户口味跨度大从用户相似度出发更容易把冷门电影挖出来这对演示效果很重要——如果推荐结果总是热门 TOP10答辩老师会觉得算法没有存在感第三UserCF 的推荐解释贴近直觉“和你口味相似的人还喜欢这部电影”比“因为你看过这部电影所以推荐那部”更容易在答辩时讲清楚。还有一种方案会拿来对比基于内容的推荐每部电影按分类、导演、主演做成特征向量推荐与你之前打过分电影相似的其他电影。这套源码没有选它原因不复杂——电影特征要靠人工维护而且内容相似不等于口味相似。一个人同时喜欢《教父》和《疯狂动物城》从内容特征上怎么也找不出关联但协同过滤可以从其他相似用户的评分里发现这条隐蔽的偏好。毕设场景下讲清楚这个选型理由比堆公式更能体现设计思考。2.2 相似度计算余弦相似度如何落到代码里UserCF 的第一步是构建 user-item 评分矩阵。行是用户列是电影单元格是评分默认 1 到 5 分0 表示未评分。有了这个矩阵就能计算两个用户之间的相似度。最常用的度量是余弦相似度把每个用户的评分看成一个多维向量夹角越小代表两个用户的口味方向越一致。两个用户 u 和 v 的余弦相似度分子是它们共同评分电影的分数乘积之和分母是两个用户评分向量模长的乘积。写成公式就是 similarity(u,v) Σ(rᵤᵢ × rᵥᵢ) / (sqrt(Σ rᵤᵢ²) × sqrt(Σ rᵥᵢ²))其中 i 遍历两个用户的共同评分电影集合。这套源码实用时做了一个简化分母遍历的是用户所有已评分项未评分位置按 0 处理0 的平方仍然是 0所以两种理解算出来的结果一致。除余弦相似度外还有皮尔逊相关系数先减去用户自己的平均分再做相关性计算能消除不同用户打分尺度不一样的影响。用户 A 习惯打 2 到 4 分用户 B 习惯打 4 到 5 分不代表 B 的口味比 A 高一倍。这套源码里的实现优先用皮尔逊但当两个用户只有一条共同评分记录时退化用余弦相似度避免除零。这个细节很重要因为冷门电影的评分很稀疏很多用户对之间只有一两条重合记录。邻居数量 K 的选择直接影响推荐质量。K 太小只有极少数用户的偏好被纳入计算结果噪声大K 太大把相似度很低的用户也拉进来了推荐结果会趋向热门电影。常见做法是先从 K10 起步看推荐列表里是否出现用户没看过的冷门电影再调整到 20 或 30 观察变化。下文的推荐引擎实现里把 K 做成一个常量方便调整。2.3 推荐引擎在 SSM 分层里的职责边界把算法放进 SSM 项目看职责很清晰。Controller 层负责暴露 HTTP 接口比如 GET /recommend/{userId}Service 层放推荐核心逻辑包括评分矩阵构建、相似度计算、最近邻选取、预测评分DAO 层由 MyBatis 的 RatingMapper 提供原始评分记录。后台管理模块是另一套独立流程管理员登录后维护电影、用户、分类信息这些操作会更新数据库进而影响下一次推荐的评分矩阵。这里有个常见误用要提醒不要把推荐逻辑写在 Controller 里。我一般会这样做——推荐引擎实现成一个独立的 RecommendService内部只依赖 RatingMapper 和 MovieMapper 两个接口。如果以后想换成 ItemCF只需要替换 RecommendService 的实现类Controller 和前端完全不用动。源码工程里就是这么拆的接口边界很清晰也是一般答辩老师喜欢看到的层次。接口设计上RecommendService 对外只暴露一个方法recommendForUser(Integer userId, int topN)内部实现细节全部隐藏。这样 SpringMVC 层不需要知道协同过滤怎么算相似度前端更不用关心。想要扩展成 ItemCF 时新增一个 ItemCFRecommendServiceImpl两个实现类并存用 Qualifier 按名字注入几行配置就能切换推荐策略这个能力在毕设创新点里很加分。3. 数据库设计五张表和一张评分表撑起整个推荐3.1 五张核心表与管理后台的关系这套系统的表设计不复杂核心是五张表用户表 user、电影表 movie、电影分类表 category、评分表 rating、管理员表 admin。用户表保存账号密码等身份信息电影表保存标题、简介、封面、上映年份、分类 ID评分表记录每个用户对每部电影的打分和时间管理员表只面向后台登录。设计上要注意两个点。第一movie 表的 category_id 关联 category 表但不要真建外键约束MyBatis 环境里外键约束容易把插入顺序和服务层事务搞复杂保留普通索引就行第二rating 表要加联合唯一索引约束同一用户对同一电影只能评一次分这是业务层面的强需求也是评分数据质量的第一道防线。3.2 建表 SQL 全文与字段选型说明CREATE TABLE user ( id INT PRIMARY KEY AUTO_INCREMENT COMMENT 用户ID, username VARCHAR(50) NOT NULL COMMENT 登录名, password VARCHAR(64) NOT NULL COMMENT 登录密码建议MD5后存储, nickname VARCHAR(50) DEFAULT NULL COMMENT 昵称用于前台展示, created_at DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT 注册时间 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT用户表; CREATE TABLE category ( id INT PRIMARY KEY AUTO_INCREMENT COMMENT 分类ID, name VARCHAR(50) NOT NULL COMMENT 分类名称如动作/科幻 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT电影分类表; CREATE TABLE movie ( id INT PRIMARY KEY AUTO_INCREMENT COMMENT 电影ID, title VARCHAR(200) NOT NULL COMMENT 电影标题, category_id INT NOT NULL COMMENT 关联分类ID, cover_url VARCHAR(255) DEFAULT NULL COMMENT 封面图地址, description TEXT COMMENT 剧情简介, release_year INT DEFAULT NULL COMMENT 上映年份, created_at DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT 录入时间, INDEX idx_category (category_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT电影表; CREATE TABLE rating ( id INT PRIMARY KEY AUTO_INCREMENT COMMENT 评分ID, user_id INT NOT NULL COMMENT 评分用户ID, movie_id INT NOT NULL COMMENT 被评分电影ID, score DECIMAL(2,1) NOT NULL COMMENT 评分值1.0-5.0允许0.5分, rating_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT 评分时间, UNIQUE KEY uk_user_movie (user_id, movie_id), INDEX idx_movie (movie_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT评分表; CREATE TABLE admin ( id INT PRIMARY KEY AUTO_INCREMENT COMMENT 管理员ID, username VARCHAR(50) NOT NULL COMMENT 管理员账号, password VARCHAR(64) NOT NULL COMMENT 管理员密码 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT管理员表;字段上注意几个细节。user.password 在演示工程里通常存 MD5 密文注册时先加密再入库登录比对时也加密后比对避免数据库里出现明文密码。rating.score 用 DECIMAL(2,1) 而不是 INT因为 4.5 分、3.5 分是很常见的评分粒度DECIMAL(2,1) 的整数部分最多 1 位小数部分 1 位足够覆盖 0.0 到 9.9。movie.description 用 TEXT 而不是 VARCHAR因为剧情简介可能超过 255 字符。rating 表的 uk_user_movie 联合唯一键是评分唯一性的兜底。前端重复提交评分时数据库层面会直接拒绝不需要在 Service 里写复杂的防重逻辑。idx_movie 索引容易被忽略推荐算法做电影维度聚合时例如统计某部电影被多少人评分这个索引能让按 movie_id 的查询走索引而不是全表扫描。3.3 评分数据从页面到推荐引擎的完整链路评分数据从哪来前台页面上每部电影有一个评分组件用户选择分数后前端用 AJAX POST 到 /movie/score 接口参数是 movieId 和 score。Controller 层接收后调用 RatingService.insertOrUpdate 方法先查一下 user_id movie_id 是否已有记录有就 UPDATE没有就 INSERT。这段逻辑很多人会写漏“先查后更新”导致重复点击评分时被 uk_user_movie 联合唯一键拦截抛 DuplicateKeyException前端表现为评分保存失败。为了避免这种问题建议在 insertOrUpdate 方法上加 Transactional 事务注解把“查 写 更新推荐缓存如果有”放在同一个事务里传播行为用默认的 REQUIRED 即可。插入成功后推荐引擎下次运行时就会把这条新评分纳入相似度计算。4. 推荐引擎代码拆解评分矩阵、KNN 和热门兜底4.1 MyBatis 层只做两件事查全量评分、查用户评分推荐引擎的入口是 RecommendService.recommendForUser(Integer userId, int topN)先通过 RatingMapper.selectAll() 把全量评分记录取出来。数据量小时直接全量查没问题几千条评分在内存里构建矩阵性能基本无感如果数据量到了十万以上再考虑按用户维度分页或降采样。select idselectAll resultTypemap SELECT user_id AS userId, movie_id AS movieId, score FROM rating /select select idselectByUser parameterTypeint resultTypemap SELECT movie_id AS movieId, score FROM rating WHERE user_id #{value} /select这两条 SQL 返回 Map 而不是实体类因为推荐引擎只需要 userId、movieId、score 三个字段Map 更轻。selectAll 用于构建全量评分矩阵selectByUser 用于获取目标用户的已评分列表两个方法的结果在代码里转成 MapInteger, MapInteger, Double 的嵌套结构外层键是用户 ID内层键是电影 ID。4.2 余弦相似度的 Java 实现与四个边界细节拿到列表后先构建评分矩阵。实际代码里我用 computeIfAbsent 简化嵌套 Map 的初始化逻辑private MapInteger, MapInteger, Double buildRatingMatrix() { ListMapString, Object list ratingMapper.selectAll(); MapInteger, MapInteger, Double matrix new HashMap(); for (MapString, Object row : list) { Integer userId (Integer) row.get(userId); Integer movieId (Integer) row.get(movieId); // DECIMAL 列会被 MyBatis 映射成 BigDecimal 或 Double统一转 double Double score ((Number) row.get(score)).doubleValue(); matrix.computeIfAbsent(userId, k - new HashMap()) .put(movieId, score); } return matrix; }这里有个容易翻车的点rating.score 在 MySQL 里是 DECIMALMyBatis 返回的可能是 BigDecimal直接用 (Double) 强转会报 ClassCastException。用 Number 类型做中转再调 doubleValue()一层转换解决所有情况。computeIfAbsent 的意思是外层 Map 里没有这个 userId 时用 lambda 创建一个新 HashMap 放进去然后往里 put 电影 ID 和评分。相似度计算的代码要写清楚它决定整个推荐质量的上限public double cosineSimilarity(MapInteger, Double user1, MapInteger, Double user2) { double dotProduct 0.0, norm1 0.0, norm2 0.0; for (Map.EntryInteger, Double entry : user1.entrySet()) { Integer movieId entry.getKey(); double score1 entry.getValue(); norm1 score1 * score1; // 只累加两个用户共同评分过的电影 Double score2 user2.get(movieId); if (score2 ! null) { dotProduct score1 * score2; } } for (double score : user2.values()) { norm2 score * score; } if (norm1 0 || norm2 0) { return 0.0; } return dotProduct / (Math.sqrt(norm1) * Math.sqrt(norm2)); }这段代码有四个关键点。第一dotProduct 只在 user2 能找到同一部电影时累加这是协同过滤的核心意义——两个用户完全没看过相同的电影相似度就是 0。第二norm1 和 norm2 是各自评分向量的模长平方最后开方做归一化。第三两个用户各自的评分数量会影响相似度评分多但共同项少的用户对会自然得到较低相似度这符合直觉。第四除零保护返回 0.0避免某个用户没有任何评分时出现 NaN。拿到所有用户对目标用户的相似度之后按值排序取前 K 个。K 在代码里定义常量 DEFAULT_NEIGHBOR_SIZE 10。实际更合适的做法是动态取相似度大于 0 的用户数如果少于 K就全部当邻居如果远远多于 K则只取前 K 个避免评分数据稀疏时推荐列表为空。4.3 Top-K 邻居加权预测组装推荐列表预测评分是推荐引擎的主干逻辑按四步走构建矩阵、算相似度、找邻居、加权预测。public ListMovieVO recommendForUser(Integer userId, int topN) { MapInteger, MapInteger, Double ratingMatrix buildRatingMatrix(); MapInteger, Double targetUserRatings ratingMatrix.get(userId); if (targetUserRatings null || targetUserRatings.isEmpty()) { return hotMoviesFallback(topN); // 冷启动兜底按热门榜推荐 } // 计算目标用户与所有其他用户的相似度 MapInteger, Double simMap new HashMap(); for (Map.EntryInteger, MapInteger, Double entry : ratingMatrix.entrySet()) { Integer otherUserId entry.getKey(); if (otherUserId.equals(userId)) { continue; // 跳过自己 } double sim cosineSimilarity(targetUserRatings, entry.getValue()); if (sim 0) { simMap.put(otherUserId, sim); } } // 相似度降序取前 K 个邻居 ListMap.EntryInteger, Double neighbors new ArrayList(simMap.entrySet()); neighbors.sort((e1, e2) - Double.compare(e2.getValue(), e1.getValue())); int k Math.min(DEFAULT_NEIGHBOR_SIZE, neighbors.size()); ListMap.EntryInteger, Double topK neighbors.subList(0, k); // 邻居评分加权累加跳过用户已经看过的电影 MapInteger, Double predictScore new HashMap(); MapInteger, Double weightSum new HashMap(); for (Map.EntryInteger, Double neighborEntry : topK) { Integer neighborId neighborEntry.getKey(); double sim neighborEntry.getValue(); MapInteger, Double neighborRatings ratingMatrix.get(neighborId); for (Map.EntryInteger, Double movieEntry : neighborRatings.entrySet()) { Integer movieId movieEntry.getKey(); if (targetUserRatings.containsKey(movieId)) { continue; } predictScore.merge(movieId, sim * movieEntry.getValue(), Double::sum); weightSum.merge(movieId, sim, Double::sum); } } // 按加权总分降序取 topN再回表查电影详情 ListMap.EntryInteger, Double result new ArrayList(predictScore.entrySet()); result.sort((e1, e2) - Double.compare(e2.getValue(), e1.getValue())); ListMovieVO recommendList new ArrayList(); for (int i 0; i Math.min(topN, result.size()); i) { Map.EntryInteger, Double item result.get(i); MovieVO vo movieMapper.findById(item.getKey()); double avgScore item.getValue() / weightSum.get(item.getKey()); vo.setPredictScore(Math.round(avgScore * 100) / 100.0); recommendList.add(vo); } return recommendList; }两个参数需要说清楚。DEFAULT_NEIGHBOR_SIZEK控制邻居窗口K 越大结果越平滑但越趋近热门K 越小越个性化但噪声越大常见做法是 10 到 30 之间先跑一轮看分布。topN 是最终返回的电影数量前端展示通常 8 到 12 比较合适。如果结果不足 topN不需要强行补齐——补热门电影会稀释算法的推荐比例宁愿让列表短一点答辩时也更好解释。兜底分支 hotMoviesFallback 是必须写的。当目标用户没有任何评分记录时协同过滤完全失效常见做法是直接返回按评分人数排序的热门电影。hotMoviesFallback 内部走 movieMapper.selectHotMovies(10)SQL 按 rating 表聚合评分人数倒序。这个分支如果不单独写新注册用户一打开推荐页就报空指针是非常典型的翻车现场。4.4 Controller 层薄封装与 JSON 响应Service 写完之后Controller 层只需要一个很薄的封装。下面是接口定义Controller RequestMapping(/recommend) public class RecommendController { Autowired private RecommendService recommendService; RequestMapping(value /{userId}, method RequestMethod.GET) ResponseBody public Result recommend(PathVariable(userId) Integer userId, RequestParam(value topN, defaultValue 8) Integer topN) { ListMovieVO list recommendService.recommendForUser(userId, topN); return Result.success(list); } }前端拿到 JSON 后渲染封面图和预测分。更灵活一点的是把 topN 做成请求参数前端传 ?topN12 就能控制列表长度现场调数字比改代码重启更有说服力。如果项目里用了 SpringMVC 的消息转换器返回 JSON 时 Jackson 会自动处理对象序列化不要自己拼 JSON 字符串——手动拼接一旦遇到中文就会乱码答辩时基本被追问到卡壳。5. 部署常见问题与避坑404、连接失败、乱码、冷启动5.1 三步把源码跑起来建库、打包、启动先把部署顺序说清楚再讲坑。拿到这份 SSM 源码后按三步走。第一步本地装好 JDK 1.8、MySQL 5.7、Maven 3.6、Tomcat 8.5 四个基础环境第二步在 MySQL 里执行工程自带的 movie_recommend.sql 脚本建库建表并灌入演示数据第三步用 IDEA 打开源码包修改 jdbc.properties 里的数据库账号密码把项目打成 war 包丢进 Tomcat 的 webapps启动后访问 http://localhost:8080/movie-recommend/。mysql -uroot -p movie_recommend.sql mvn clean package -DskipTests cp target/movie-recommend.war $CATALINA_HOME/webapps/ $CATALINA_HOME/bin/startup.sh第三步看起来简单但有两个隐藏细节。war 包名称就是访问路径如果不想带版本号在 pom.xml 里把 设成 movie-recommendstartup.sh 启动后不要急着访问页面先看 logs/catalina.out 里有没有 Exception确认启动成功再开浏览器。Windows 下也可以进入 mysql 命令行后执行 source C:/movie_recommend.sql效果一样。5.2 Tomcat 404先把部署和 artifact 配置对现象Tomcat 正常启动访问首页返回 404但 catalina.out 里没有任何异常。原因工程没被打进 webapps。这种情况常见于直接用 IDEA 的 Run 按钮跑 Tomcat 插件但 artifact 配置里没有把项目 modules 加进 deployment相当于 Tomcat 起来了但项目根本没部署。解决在 IDEA 的 Deployment 面板确认有带 war exploded 字样的条目或者手动 mvn clean package把 war 放进 Tomcat 的 webapps 用 startup.sh 启动后者更贴近部署环境也更好排查。5.3 MySQL 连接失败驱动类名与连接串参数现象项目启动时日志出现 Cannot create PoolableConnectionFactory底层是 Communications link failure。原因最常见的是 MySQL 驱动版本和数据库版本不匹配以及连接串少参数。解决用 mysql-connector-java 8.0.x 时jdbc.url 必须带 serverTimezoneAsia/Shanghai 和 useSSLfalse否则高版本 MySQL 会因时区不明直接拒绝建连。下面是一份可用的 jdbc.propertiesjdbc.drivercom.mysql.cj.jdbc.Driver jdbc.urljdbc:mysql://localhost:3306/movie_recommend?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalse jdbc.usernameroot jdbc.password123456jdbc.driver 要留意MySQL 8.x 驱动类名是 com.mysql.cj.jdbc.Driver老项目里常写 com.mysql.jdbc.Driver虽然 8.x 驱动仍兼容老类名但控制台会打 WARN建议直接换成新类名。password 如果含有 、# 特殊字符在 properties 文件里直接写不要加双引号。5.4 中文乱码三个环节统一 UTF-8现象电影标题显示成 æ 或 î½管理后台明明看到数据库里是中文。原因链路里字符集不一致。MySQL 建库用 utf8mb4但 Java 侧的 jdbc.url 没带 characterEncodingutf8或者 Tomcat 的 URIEncoding 没设置。解决三层统一。数据库连接串加 characterEncodingutf8Tomcat 的 server.xml 里 Connector 增加 URIEncodingUTF-8工程加一个 SpringMVC 字符编码过滤器 CharacterEncodingFilter强制 request 和 response 都走 UTF-8三处配齐后基本不会再出乱码。另外要区分一种情况接口返回的 JSON 里中文全部变成 \u5f71\u8bc4 这类转义序列这不是乱码是 Jackson 默认的 ASCII 输出行为。想要可读的中文在 spring-mvc.xml 里配置消息转换器将 ObjectMapper 的 WRITE_NON_ASCII 关闭即可。不影响功能但排查时很唬人。5.5 新用户推荐为空用热门兜底替代报错现象刚注册的用户进入首页推荐位一片空白控制台也没有报错。原因recommendForUser 里 targetUserRatings 为空时直接返回了空列表没有走冷启动兜底。解决在入口处判断用户无评分时调 hotMoviesFallback把热门电影当作推荐结果。这不是偷懒是协同过滤本身解决不了新用户问题业界通用方案就是热度兜底。这里有个进阶技巧与其让前端等到接口返回空数组再拉热门电影不如在后端把兜底结果和推荐结果合并返回响应体里加一个 source 字段值是 collaborative 或 fallback。前端拿到 fallback 时展示“根据热门榜单推荐”拿到 collaborative 时展示“根据你的口味推荐”演示时系统看起来聪明很多。6. 验证推荐算法5 个用户的评分矩阵手算一遍相似度拿到源码的第一件事不是急着加功能而是先验证算法到底算得对不对。我的习惯是先构造一套 5 个用户、10 部电影的评分数据手工算一遍余弦相似度再用程序跑一遍两个结果逐项对比不一致就去查代码。用户电影1电影2电影3用户A530用户B534用户C051对用户 A 和 B共同评分电影是电影1、电影2。分子是 5×5 3×3 34A 的模长是 sqrt(259) ≈ 5.83B 的模长是 sqrt(25916) ≈ 7.07相似度就是 34 / (5.83 × 7.07) ≈ 0.825。程序打印出来如果差太多先检查是不是把未评分项当成 0 参与相似度计算了——把未评分当 0 是新手最常见的错它会让两个用户的相似度虚高。再验证一组用户 C 和 A 只有一个共同评分项相似度按公式算约等于 0.505和 0.825 放在一起看能明显区分出“关系远”和“关系近”。验证完相似度再调两个参数。DEFAULT_NEIGHBOR_SIZE 从 10 改成 20看推荐列表里是不是多了评分人数更多的热门片topN 从 8 改成 12看预测分最低的几部电影有没有明显离群值。正常表现是 K 翻倍后推荐结果的重合度在五成到七成如果完全不变多半是 simMap 里所有用户相似度都一样回去查评分矩阵的 key 是否在构建时被覆盖了。我已经不止一次遇到这种情况评分矩阵 Map 的 key 写错把所有用户的评分塞到同一个键下面相似度全是 1.0推荐列表直接变成“全班平均分排行榜”。从那以后我每次拿到推荐类源码都强制走一遍“造数据 → 手算 → 跑程序 → 对比 → 调参”这个流程再轻量的 demo 也不跳步能挡掉九成“玄学推荐”的坑。希望帮到你。本文还有配套的精品资源点击获取