尧图网站建设 
简介这是一套面向Java方向毕业设计的学习资源基于SSM框架与协同过滤算法实现了一个在线通用旅游平台网站适合正在准备毕设的计算机专业学生以及希望练习前后端整合开发的初中级开发者。压缩包内共1288个文件约52.7MB涵盖java源码、jsp页面、js脚本、css样式、html页面、xml配置、properties配置、sql数据库脚本以及jar依赖包等前端、后端与MySQL数据库源码齐全可直接部署运行。系统功能围绕景点推荐管理、精选路线管理、用户信息管理和系统管理四大模块展开其中景点推荐模块支持景点信息的添加、修改、删除与查询精选路线模块可为游客提供更合适的出行路线系统管理则包含公告、简介、在线留言与站内新闻等管理员常用功能。协同过滤算法的引入使景点推荐更具个性化读者可借此理解推荐算法在真实项目中的落地方式并参考其分层结构与数据库设计完成自己的毕设方案。目前已有58人学习。1. 一个 SSM 旅游平台毕设为什么协同过滤才是它的核心看点如果你正在找 Java 毕业设计大概率已经翻过一堆“XX 管理系统”——增删改查堆出来的那种跑起来能交差但答辩时老师一句“创新点在哪”就能把你问住。这份基于 SSM 的在线通用旅游平台源码真正值得拆的地方不在景点管理、路线管理这些常规模块而在于它把协同过滤塞进了推荐环节。旅游场景天然适合做推荐用户对景点的评分、浏览、收藏行为可以转化成用户-物品矩阵再用相似度算出“和你口味相近的人还去了哪”。这套源码前端后端加 MySQL 是完整的SSM 三层结构清晰适合拿来当毕设底子改也适合想搞懂推荐算法怎么落进 Java Web 项目的人。它解决的不是“有没有系统”的问题而是“系统里有没有一个能讲出算法逻辑的模块”。2. 协同过滤在 SSM 里怎么落地从用户-景点评分矩阵到推荐结果2.1 为什么旅游平台适合用协同过滤而不是规则推荐规则推荐是“热门景点排前面”或者“按价格筛”逻辑写死在 SQL 里答辩时没法展开。协同过滤不一样它的前提是用户行为数据能构成矩阵行是用户列是景点格子里是评分或隐式反馈浏览、收藏、下单。旅游平台的数据天然满足这个结构——一个用户去过几个景点、打了分不同用户之间就能算相似度。常见做法是基于用户的协同过滤UserCF找和你相似的一批人把他们高分但你没去过的景点推给你。也有基于物品的ItemCF算景点之间的相似度适合景点数量远小于用户数量的场景。这份源码用的是 UserCF 思路因为毕设数据量小用户数通常几百条UserCF 的邻域计算更直观答辩时画个矩阵图就能讲清楚。选 UserCF 还有一个现实原因SSM 项目里用 Java 实现矩阵运算不需要引入 Spark 或 Mahout 这种重依赖。用 Map 存用户评分、用余弦相似度算距离几十行代码就能跑通。对于毕设来说能跑、能讲、能改比用现成推荐引擎更实在。2.2 用户-景点评分矩阵的构建与相似度计算协同过滤的第一步是把散落在各张表里的行为数据聚成矩阵。旅游平台通常有用户表、景点表、订单表、评论表。评分来源可以是评论里的星级也可以是订单完成后的默认好评。我一般会先从评论表里取 user_id、scenic_id、score 三个字段构建一个MapLong, MapLong, Double结构外层 key 是用户 ID内层 key 是景点 IDvalue 是评分。// 构建用户-景点评分矩阵 public MapLong, MapLong, Double buildUserItemMatrix() { MapLong, MapLong, Double matrix new HashMap(); // 从评论表查询所有评分记录 ListComment comments commentMapper.selectAllWithScore(); for (Comment c : comments) { Long userId c.getUserId(); Long scenicId c.getScenicId(); Double score c.getScore(); // 如果该用户还没有评分记录先初始化内层 Map matrix.computeIfAbsent(userId, k - new HashMap()).put(scenicId, score); } return matrix; }这段代码的逻辑很直白遍历评论表把每条评分塞进两层 Map。computeIfAbsent保证用户第一次出现时自动创建内层 Map避免空指针。参数上要注意 score 的类型如果数据库存的是整数星级转 Double 时别丢精度如果评分范围是 1-5后续算相似度时不需要归一化余弦相似度本身对量纲不敏感。相似度计算用余弦公式两个用户的评分向量夹角的余弦值。代码里把两个用户共同评分的景点取交集分别算点积和模长。// 计算两个用户的余弦相似度 public double cosineSimilarity(MapLong, Double user1, MapLong, Double user2) { double dotProduct 0.0, norm1 0.0, norm2 0.0; for (Long scenicId : user1.keySet()) { if (user2.containsKey(scenicId)) { dotProduct user1.get(scenicId) * user2.get(scenicId); } } for (Double score : user1.values()) { norm1 Math.pow(score, 2); } for (Double score : user2.values()) { norm2 Math.pow(score, 2); } if (norm1 0 || norm2 0) return 0.0; return dotProduct / (Math.sqrt(norm1) * Math.sqrt(norm2)); }这里有个容易翻车的地方如果两个用户没有共同评分的景点点积为 0相似度就是 0这是合理的。但如果某个用户评分全是 0 分比如默认值没过滤模长为 0 会导致除零。所以代码里加了norm1 0的判断。参数上user1.keySet()遍历的是该用户评过分的景点只在这些景点里找交集比全表遍历快得多。2.3 推荐结果生成与 SSM 服务层整合算出相似度之后取 Top-N 个最相似的用户把他们评过高分、但目标用户没评过的景点加权汇总排序取前 K 个作为推荐。加权公式是相似度 × 评分累加后除以相似度之和得到预测评分。// 为目标用户生成推荐景点列表 public ListLong recommendScenics(Long targetUserId, int topN, int recommendNum) { MapLong, MapLong, Double matrix buildUserItemMatrix(); MapLong, Double targetRatings matrix.get(targetUserId); if (targetRatings null) return Collections.emptyList(); // 计算目标用户与其他所有用户的相似度 ListUserSimilarity similarities new ArrayList(); for (Map.EntryLong, MapLong, Double entry : matrix.entrySet()) { if (entry.getKey().equals(targetUserId)) continue; double sim cosineSimilarity(targetRatings, entry.getValue()); if (sim 0) { similarities.add(new UserSimilarity(entry.getKey(), sim)); } } // 按相似度降序取前 topN 个邻居 similarities.sort((a, b) - Double.compare(b.getSimilarity(), a.getSimilarity())); ListUserSimilarity neighbors similarities.subList(0, Math.min(topN, similarities.size())); // 加权汇总邻居的评分 MapLong, Double weightedScores new HashMap(); MapLong, Double simSums new HashMap(); for (UserSimilarity neighbor : neighbors) { MapLong, Double neighborRatings matrix.get(neighbor.getUserId()); for (Map.EntryLong, Double rating : neighborRatings.entrySet()) { Long scenicId rating.getKey(); if (targetRatings.containsKey(scenicId)) continue; // 跳过已评分的 weightedScores.merge(scenicId, neighbor.getSimilarity() * rating.getValue(), Double::sum); simSums.merge(scenicId, neighbor.getSimilarity(), Double::sum); } } // 计算预测评分并排序 ListMap.EntryLong, Double predictions new ArrayList(); for (Long scenicId : weightedScores.keySet()) { double predicted weightedScores.get(scenicId) / simSums.get(scenicId); predictions.add(new AbstractMap.SimpleEntry(scenicId, predicted)); } predictions.sort((a, b) - Double.compare(b.getValue(), a.getValue())); return predictions.stream().limit(recommendNum).map(Map.Entry::getKey).collect(Collectors.toList()); }这段代码是推荐模块的核心。topN控制邻居数量一般取 10-20太小推荐不准太大计算慢且引入噪声。recommendNum是最终返回的景点数首页一般展示 5-8 个。simSums用来做加权平均的分母避免相似度高的邻居因为评分多而过度影响结果。整合到 SSM 时把这个 Service 注入 Controller在首页接口里调用把返回的景点 ID 列表再查一次景点表拿详情塞进 Model 返回给 JSP 或前端页面。提示如果数据库里评分数据太少比如只有几十条协同过滤会退化成“随机推荐”。毕设演示前建议手动造一批评分数据覆盖至少 20 个用户和 30 个景点矩阵稀疏度控制在 30% 左右推荐结果才有区分度。3. 把源码跑起来环境配置、数据库导入与前后端联调3.1 SSM 项目结构拆解与依赖版本确认拿到这份源码先别急着改代码花十分钟把目录结构看清楚。典型的 SSM 项目分三层src/main/java下按controller、service、mapper、entity分包src/main/resources放spring-*.xml、mybatis-config.xml、jdbc.propertieswebapp下是 JSP 页面和静态资源。这份旅游平台源码的包名一般是com.tourism或类似Controller 里处理页面跳转和接口请求Service 写业务逻辑Mapper 接口配 XML 文件写 SQL。依赖版本是第一个要确认的点。SSM 项目常见的坑是 Spring 和 MyBatis 版本不匹配导致启动报NoSuchMethodError。打开pom.xml重点看三组坐标spring-context、spring-webmvc、mybatis-spring。常见稳定组合是 Spring 5.2.x MyBatis 3.5.x mybatis-spring 2.0.x。如果源码里用的是 Spring 4.xJDK 版本要降到 8用 JDK 11 以上可能遇到javax.xml.bind缺失的问题需要手动加 JAXB 依赖。!-- pom.xml 关键依赖片段 -- properties spring.version5.2.8.RELEASE/spring.version mybatis.version3.5.6/mybatis.version /properties dependencies dependency groupIdorg.springframework/groupId artifactIdspring-context/artifactId version${spring.version}/version /dependency dependency groupIdorg.springframework/groupId artifactIdspring-webmvc/artifactId version${spring.version}/version /dependency dependency groupIdorg.mybatis/groupId artifactIdmybatis/artifactId version${mybatis.version}/version /dependency dependency groupIdorg.mybatis/groupId artifactIdmybatis-spring/artifactId version2.0.6/version /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId version8.0.21/version /dependency /dependencies参数说明spring.version统一管理 Spring 各模块版本避免冲突mybatis-spring是 MyBatis 和 Spring 的粘合包版本必须和 MyBatis 主版本对应MySQL 驱动 8.x 需要配com.mysql.cj.jdbc.Driver5.x 用com.mysql.jdbc.Driver写错会报驱动找不到。3.2 数据库导入与 jdbc.properties 配置源码包里一般有个sql文件夹里面是.sql建表语句和数据。用 Navicat 或命令行导入之前先建一个空库字符集选utf8mb4排序规则utf8mb4_general_ci。导入时注意 SQL 文件里如果有CREATE DATABASE语句库名可能和你的不一致手动改成自己的库名再执行。# 命令行导入示例 mysql -u root -p CREATE DATABASE tourism_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE tourism_db; SOURCE /path/to/tourism.sql;导入完成后检查三张核心表user用户、scenic景点、comment评论。评论表里要有user_id、scenic_id、score字段这是协同过滤的数据来源。如果源码里评论表叫evaluate或review去 Mapper XML 里搜对应的表名别改错。接着改jdbc.propertiesjdbc.drivercom.mysql.cj.jdbc.Driver jdbc.urljdbc:mysql://localhost:3306/tourism_db?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalse jdbc.usernameroot jdbc.password你的密码serverTimezone必须加MySQL 8 不配这个会报时区错误。useSSLfalse在本地开发时关掉避免证书警告。characterEncodingutf8保证中文不乱码。改完这些把项目部署到 Tomcat 8.5 或 9.0启动看控制台有没有BeanCreationException有的话多半是 XML 里 bean 的 id 和 ref 对不上。3.3 前后端联调与推荐接口验证项目跑起来后先访问登录页用 SQL 里预置的管理员账号登进去。如果登录报 500看logs目录或控制台堆栈常见原因是jdbc.properties没被加载检查spring-mybatis.xml里context:property-placeholder的location路径。推荐接口的验证分两步。第一步直接访问推荐页看有没有景点列表返回。第二步手动往评论表插几条评分数据刷新页面看推荐结果有没有变化。-- 插入测试评分数据验证协同过滤是否生效 INSERT INTO comment (user_id, scenic_id, score, content, create_time) VALUES (1, 101, 5, 风景很好, NOW()), (1, 102, 4, 值得一去, NOW()), (2, 101, 4, 还不错, NOW()), (2, 103, 5, 强烈推荐, NOW()), (3, 102, 5, 很美, NOW()), (3, 103, 4, 可以, NOW());插完数据后用 user_id1 访问推荐接口理论上应该推荐 103因为用户 2 和 3 都给了 103 高分且和用户 1 有共同评分景点。如果推荐结果为空检查cosineSimilarity里有没有因为共同评分景点太少导致相似度为 0。这是冷启动的典型表现不是代码 bug是数据不够。注意Tomcat 部署时如果项目路径带中文或空格JSP 页面可能 404。把 war 包名改成纯英文比如tourism.war访问路径就是http://localhost:8080/tourism/。4. 避坑与排查协同过滤和 SSM 整合中最容易翻车的五个点4.1 相似度全为 0推荐结果永远是空现象推荐接口返回空列表日志里没有异常但就是没数据。原因通常是用户-景点矩阵太稀疏两个用户之间没有共同评分的景点余弦相似度算出来全是 0。解决在recommendScenics里加一个兜底逻辑如果邻居列表为空就返回按平均分排序的热门景点。另外毕设演示前用 SQL 批量造数据保证每个用户至少评 3 个景点景点之间有一定重叠。4.2 MyBatis 映射字段与实体类属性对不上现象查询不报错但返回的对象字段全是 null。原因Mapper XML 里的resultMap列名和实体类属性名不一致比如数据库列是user_id实体类属性是userId但resultMap里没配column和property的映射。解决在mybatis-config.xml里开启mapUnderscoreToCamelCasetrue让下划线自动转驼峰。如果还不行手动检查resultMap的每一行。4.3 Spring 事务不生效插入评分后推荐没更新现象手动插了评论数据但推荐结果没变。原因Service 类没有加Transactional或者加了但 XML 里没开tx:annotation-driven。更隐蔽的情况是推荐方法内部调用了同类的方法Spring AOP 代理失效。解决确认spring-service.xml里有事务注解驱动推荐方法直接查数据库而不是走缓存。如果用了 MyBatis 二级缓存清一下缓存或关掉。4.4 中文乱码从 JSP 一路乱到数据库现象页面输入中文存进数据库变成问号。原因JSP 页面没设pageEncodingUTF-8或者 web.xml 里没配CharacterEncodingFilter或者数据库连接串没加characterEncodingutf8。解决三处都检查。JSP 头部加% page contentTypetext/html;charsetUTF-8 languagejava %web.xml 配过滤器jdbc.url加characterEncodingutf8。4.5 Tomcat 启动报 ClassNotFoundException 但依赖明明导入了现象IDEA 里依赖都在Tomcat 启动就是报类找不到。原因依赖没有打包到WEB-INF/lib下或者 IDEA 的 Artifact 配置里漏了库。解决在 Project Structure 的 Artifacts 里确认Available Elements中的依赖都双击加到了WEB-INF/lib下。或者直接用 Maven 的package命令打 war 包比 IDEA 的 Artifact 更可靠。5. 让推荐结果经得起答辩评分数据构造与算法参数调优5.1 用 SQL 批量构造有区分度的评分矩阵毕设演示最怕推荐结果“看起来像随机”。要让协同过滤跑出效果评分矩阵得有结构一部分用户口味相似一部分用户口味分散。我一般用 SQL 的INSERT ... SELECT配合随机函数造数据但随机太均匀反而没区分度。更好的做法是分三组用户第一组偏爱自然风光类景点ID 101-110第二组偏爱人文历史类111-120第三组随机。每组内用户的评分有重叠组间重叠少。-- 构造三组用户评分数据每组口味不同 -- 第一组用户 1-10偏爱景点 101-110 INSERT INTO comment (user_id, scenic_id, score, content, create_time) SELECT u.id, s.id, 4 (u.id s.id) % 2, 不错, NOW() FROM user u, scenic s WHERE u.id BETWEEN 1 AND 10 AND s.id BETWEEN 101 AND 110 AND (u.id s.id) % 3 ! 0; -- 制造部分缺失模拟真实稀疏 -- 第二组用户 11-20偏爱景点 111-120 INSERT INTO comment (user_id, scenic_id, score, content, create_time) SELECT u.id, s.id, 4 (u.id s.id) % 2, 很好, NOW() FROM user u, scenic s WHERE u.id BETWEEN 11 AND 20 AND s.id BETWEEN 111 AND 120 AND (u.id s.id) % 3 ! 0;这样造出来的矩阵用户 1 和用户 2 在 101-110 上有大量共同评分相似度高用户 1 和用户 11 几乎没有交集相似度低。推荐时用户 1 会优先收到 101-110 里他没评过的景点而不是 111-120 的。答辩时把这个逻辑讲清楚比说“用了协同过滤”有说服力得多。5.2 邻居数量 K 和推荐数量 N 的调参经验topN邻居数和recommendNum推荐数没有标准答案但有几个经验值。邻居数 K 一般取 10-20。K 太小比如 3推荐结果受个别用户影响大不稳定K 太大比如 50会把不相似的用户也拉进来推荐精度下降。推荐数 N 看页面展示位置首页取 5-8 个详情页“猜你喜欢”取 3-5 个。调参时可以用一个简单指标覆盖率。统计推荐结果里有多少景点是用户没看过但属于他偏好类别的。如果覆盖率低于 30%说明 K 太大或数据太稀疏如果高于 80%可能过拟合推荐来推荐去就那几个。我一般会在 Service 里加个日志把每次推荐的邻居 ID 和相似度打出来观察几轮再定参数。5.3 从 UserCF 切到 ItemCF 的改造思路如果答辩老师问“用户多了怎么办”UserCF 的瓶颈是用户数增长时相似度计算量平方级上升。这时候可以切到 ItemCF算景点之间的相似度推荐时看用户评过分的景点和哪些景点相似。改造点主要在buildUserItemMatrix之后把矩阵转置成景点-用户相似度计算逻辑不变只是遍历方向反过来。ItemCF 的另一个好处是景点数量通常比用户少矩阵更小计算更快。源码里如果预留了接口改起来就是换个实现类的事。从那以后我每次拿到 SSM 毕设源码都先跑通登录和列表页再单独把推荐模块拎出来用 SQL 造数据验证最后才调页面样式。这套顺序能避免在环境问题上耗太久也能让推荐算法在答辩时真正成为亮点。希望帮到你。本文还有配套的精品资源点击获取 SSM旅游平台毕设：协同过滤推荐算法落地与调优
简介这是一套面向Java方向毕业设计的学习资源基于SSM框架与协同过滤算法实现了一个在线通用旅游平台网站适合正在准备毕设的计算机专业学生以及希望练习前后端整合开发的初中级开发者。压缩包内共1288个文件约52.7MB涵盖java源码、jsp页面、js脚本、css样式、html页面、xml配置、properties配置、sql数据库脚本以及jar依赖包等前端、后端与MySQL数据库源码齐全可直接部署运行。系统功能围绕景点推荐管理、精选路线管理、用户信息管理和系统管理四大模块展开其中景点推荐模块支持景点信息的添加、修改、删除与查询精选路线模块可为游客提供更合适的出行路线系统管理则包含公告、简介、在线留言与站内新闻等管理员常用功能。协同过滤算法的引入使景点推荐更具个性化读者可借此理解推荐算法在真实项目中的落地方式并参考其分层结构与数据库设计完成自己的毕设方案。目前已有58人学习。1. 一个 SSM 旅游平台毕设为什么协同过滤才是它的核心看点如果你正在找 Java 毕业设计大概率已经翻过一堆“XX 管理系统”——增删改查堆出来的那种跑起来能交差但答辩时老师一句“创新点在哪”就能把你问住。这份基于 SSM 的在线通用旅游平台源码真正值得拆的地方不在景点管理、路线管理这些常规模块而在于它把协同过滤塞进了推荐环节。旅游场景天然适合做推荐用户对景点的评分、浏览、收藏行为可以转化成用户-物品矩阵再用相似度算出“和你口味相近的人还去了哪”。这套源码前端后端加 MySQL 是完整的SSM 三层结构清晰适合拿来当毕设底子改也适合想搞懂推荐算法怎么落进 Java Web 项目的人。它解决的不是“有没有系统”的问题而是“系统里有没有一个能讲出算法逻辑的模块”。2. 协同过滤在 SSM 里怎么落地从用户-景点评分矩阵到推荐结果2.1 为什么旅游平台适合用协同过滤而不是规则推荐规则推荐是“热门景点排前面”或者“按价格筛”逻辑写死在 SQL 里答辩时没法展开。协同过滤不一样它的前提是用户行为数据能构成矩阵行是用户列是景点格子里是评分或隐式反馈浏览、收藏、下单。旅游平台的数据天然满足这个结构——一个用户去过几个景点、打了分不同用户之间就能算相似度。常见做法是基于用户的协同过滤UserCF找和你相似的一批人把他们高分但你没去过的景点推给你。也有基于物品的ItemCF算景点之间的相似度适合景点数量远小于用户数量的场景。这份源码用的是 UserCF 思路因为毕设数据量小用户数通常几百条UserCF 的邻域计算更直观答辩时画个矩阵图就能讲清楚。选 UserCF 还有一个现实原因SSM 项目里用 Java 实现矩阵运算不需要引入 Spark 或 Mahout 这种重依赖。用 Map 存用户评分、用余弦相似度算距离几十行代码就能跑通。对于毕设来说能跑、能讲、能改比用现成推荐引擎更实在。2.2 用户-景点评分矩阵的构建与相似度计算协同过滤的第一步是把散落在各张表里的行为数据聚成矩阵。旅游平台通常有用户表、景点表、订单表、评论表。评分来源可以是评论里的星级也可以是订单完成后的默认好评。我一般会先从评论表里取 user_id、scenic_id、score 三个字段构建一个MapLong, MapLong, Double结构外层 key 是用户 ID内层 key 是景点 IDvalue 是评分。// 构建用户-景点评分矩阵 public MapLong, MapLong, Double buildUserItemMatrix() { MapLong, MapLong, Double matrix new HashMap(); // 从评论表查询所有评分记录 ListComment comments commentMapper.selectAllWithScore(); for (Comment c : comments) { Long userId c.getUserId(); Long scenicId c.getScenicId(); Double score c.getScore(); // 如果该用户还没有评分记录先初始化内层 Map matrix.computeIfAbsent(userId, k - new HashMap()).put(scenicId, score); } return matrix; }这段代码的逻辑很直白遍历评论表把每条评分塞进两层 Map。computeIfAbsent保证用户第一次出现时自动创建内层 Map避免空指针。参数上要注意 score 的类型如果数据库存的是整数星级转 Double 时别丢精度如果评分范围是 1-5后续算相似度时不需要归一化余弦相似度本身对量纲不敏感。相似度计算用余弦公式两个用户的评分向量夹角的余弦值。代码里把两个用户共同评分的景点取交集分别算点积和模长。// 计算两个用户的余弦相似度 public double cosineSimilarity(MapLong, Double user1, MapLong, Double user2) { double dotProduct 0.0, norm1 0.0, norm2 0.0; for (Long scenicId : user1.keySet()) { if (user2.containsKey(scenicId)) { dotProduct user1.get(scenicId) * user2.get(scenicId); } } for (Double score : user1.values()) { norm1 Math.pow(score, 2); } for (Double score : user2.values()) { norm2 Math.pow(score, 2); } if (norm1 0 || norm2 0) return 0.0; return dotProduct / (Math.sqrt(norm1) * Math.sqrt(norm2)); }这里有个容易翻车的地方如果两个用户没有共同评分的景点点积为 0相似度就是 0这是合理的。但如果某个用户评分全是 0 分比如默认值没过滤模长为 0 会导致除零。所以代码里加了norm1 0的判断。参数上user1.keySet()遍历的是该用户评过分的景点只在这些景点里找交集比全表遍历快得多。2.3 推荐结果生成与 SSM 服务层整合算出相似度之后取 Top-N 个最相似的用户把他们评过高分、但目标用户没评过的景点加权汇总排序取前 K 个作为推荐。加权公式是相似度 × 评分累加后除以相似度之和得到预测评分。// 为目标用户生成推荐景点列表 public ListLong recommendScenics(Long targetUserId, int topN, int recommendNum) { MapLong, MapLong, Double matrix buildUserItemMatrix(); MapLong, Double targetRatings matrix.get(targetUserId); if (targetRatings null) return Collections.emptyList(); // 计算目标用户与其他所有用户的相似度 ListUserSimilarity similarities new ArrayList(); for (Map.EntryLong, MapLong, Double entry : matrix.entrySet()) { if (entry.getKey().equals(targetUserId)) continue; double sim cosineSimilarity(targetRatings, entry.getValue()); if (sim 0) { similarities.add(new UserSimilarity(entry.getKey(), sim)); } } // 按相似度降序取前 topN 个邻居 similarities.sort((a, b) - Double.compare(b.getSimilarity(), a.getSimilarity())); ListUserSimilarity neighbors similarities.subList(0, Math.min(topN, similarities.size())); // 加权汇总邻居的评分 MapLong, Double weightedScores new HashMap(); MapLong, Double simSums new HashMap(); for (UserSimilarity neighbor : neighbors) { MapLong, Double neighborRatings matrix.get(neighbor.getUserId()); for (Map.EntryLong, Double rating : neighborRatings.entrySet()) { Long scenicId rating.getKey(); if (targetRatings.containsKey(scenicId)) continue; // 跳过已评分的 weightedScores.merge(scenicId, neighbor.getSimilarity() * rating.getValue(), Double::sum); simSums.merge(scenicId, neighbor.getSimilarity(), Double::sum); } } // 计算预测评分并排序 ListMap.EntryLong, Double predictions new ArrayList(); for (Long scenicId : weightedScores.keySet()) { double predicted weightedScores.get(scenicId) / simSums.get(scenicId); predictions.add(new AbstractMap.SimpleEntry(scenicId, predicted)); } predictions.sort((a, b) - Double.compare(b.getValue(), a.getValue())); return predictions.stream().limit(recommendNum).map(Map.Entry::getKey).collect(Collectors.toList()); }这段代码是推荐模块的核心。topN控制邻居数量一般取 10-20太小推荐不准太大计算慢且引入噪声。recommendNum是最终返回的景点数首页一般展示 5-8 个。simSums用来做加权平均的分母避免相似度高的邻居因为评分多而过度影响结果。整合到 SSM 时把这个 Service 注入 Controller在首页接口里调用把返回的景点 ID 列表再查一次景点表拿详情塞进 Model 返回给 JSP 或前端页面。提示如果数据库里评分数据太少比如只有几十条协同过滤会退化成“随机推荐”。毕设演示前建议手动造一批评分数据覆盖至少 20 个用户和 30 个景点矩阵稀疏度控制在 30% 左右推荐结果才有区分度。3. 把源码跑起来环境配置、数据库导入与前后端联调3.1 SSM 项目结构拆解与依赖版本确认拿到这份源码先别急着改代码花十分钟把目录结构看清楚。典型的 SSM 项目分三层src/main/java下按controller、service、mapper、entity分包src/main/resources放spring-*.xml、mybatis-config.xml、jdbc.propertieswebapp下是 JSP 页面和静态资源。这份旅游平台源码的包名一般是com.tourism或类似Controller 里处理页面跳转和接口请求Service 写业务逻辑Mapper 接口配 XML 文件写 SQL。依赖版本是第一个要确认的点。SSM 项目常见的坑是 Spring 和 MyBatis 版本不匹配导致启动报NoSuchMethodError。打开pom.xml重点看三组坐标spring-context、spring-webmvc、mybatis-spring。常见稳定组合是 Spring 5.2.x MyBatis 3.5.x mybatis-spring 2.0.x。如果源码里用的是 Spring 4.xJDK 版本要降到 8用 JDK 11 以上可能遇到javax.xml.bind缺失的问题需要手动加 JAXB 依赖。!-- pom.xml 关键依赖片段 -- properties spring.version5.2.8.RELEASE/spring.version mybatis.version3.5.6/mybatis.version /properties dependencies dependency groupIdorg.springframework/groupId artifactIdspring-context/artifactId version${spring.version}/version /dependency dependency groupIdorg.springframework/groupId artifactIdspring-webmvc/artifactId version${spring.version}/version /dependency dependency groupIdorg.mybatis/groupId artifactIdmybatis/artifactId version${mybatis.version}/version /dependency dependency groupIdorg.mybatis/groupId artifactIdmybatis-spring/artifactId version2.0.6/version /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId version8.0.21/version /dependency /dependencies参数说明spring.version统一管理 Spring 各模块版本避免冲突mybatis-spring是 MyBatis 和 Spring 的粘合包版本必须和 MyBatis 主版本对应MySQL 驱动 8.x 需要配com.mysql.cj.jdbc.Driver5.x 用com.mysql.jdbc.Driver写错会报驱动找不到。3.2 数据库导入与 jdbc.properties 配置源码包里一般有个sql文件夹里面是.sql建表语句和数据。用 Navicat 或命令行导入之前先建一个空库字符集选utf8mb4排序规则utf8mb4_general_ci。导入时注意 SQL 文件里如果有CREATE DATABASE语句库名可能和你的不一致手动改成自己的库名再执行。# 命令行导入示例 mysql -u root -p CREATE DATABASE tourism_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE tourism_db; SOURCE /path/to/tourism.sql;导入完成后检查三张核心表user用户、scenic景点、comment评论。评论表里要有user_id、scenic_id、score字段这是协同过滤的数据来源。如果源码里评论表叫evaluate或review去 Mapper XML 里搜对应的表名别改错。接着改jdbc.propertiesjdbc.drivercom.mysql.cj.jdbc.Driver jdbc.urljdbc:mysql://localhost:3306/tourism_db?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalse jdbc.usernameroot jdbc.password你的密码serverTimezone必须加MySQL 8 不配这个会报时区错误。useSSLfalse在本地开发时关掉避免证书警告。characterEncodingutf8保证中文不乱码。改完这些把项目部署到 Tomcat 8.5 或 9.0启动看控制台有没有BeanCreationException有的话多半是 XML 里 bean 的 id 和 ref 对不上。3.3 前后端联调与推荐接口验证项目跑起来后先访问登录页用 SQL 里预置的管理员账号登进去。如果登录报 500看logs目录或控制台堆栈常见原因是jdbc.properties没被加载检查spring-mybatis.xml里context:property-placeholder的location路径。推荐接口的验证分两步。第一步直接访问推荐页看有没有景点列表返回。第二步手动往评论表插几条评分数据刷新页面看推荐结果有没有变化。-- 插入测试评分数据验证协同过滤是否生效 INSERT INTO comment (user_id, scenic_id, score, content, create_time) VALUES (1, 101, 5, 风景很好, NOW()), (1, 102, 4, 值得一去, NOW()), (2, 101, 4, 还不错, NOW()), (2, 103, 5, 强烈推荐, NOW()), (3, 102, 5, 很美, NOW()), (3, 103, 4, 可以, NOW());插完数据后用 user_id1 访问推荐接口理论上应该推荐 103因为用户 2 和 3 都给了 103 高分且和用户 1 有共同评分景点。如果推荐结果为空检查cosineSimilarity里有没有因为共同评分景点太少导致相似度为 0。这是冷启动的典型表现不是代码 bug是数据不够。注意Tomcat 部署时如果项目路径带中文或空格JSP 页面可能 404。把 war 包名改成纯英文比如tourism.war访问路径就是http://localhost:8080/tourism/。4. 避坑与排查协同过滤和 SSM 整合中最容易翻车的五个点4.1 相似度全为 0推荐结果永远是空现象推荐接口返回空列表日志里没有异常但就是没数据。原因通常是用户-景点矩阵太稀疏两个用户之间没有共同评分的景点余弦相似度算出来全是 0。解决在recommendScenics里加一个兜底逻辑如果邻居列表为空就返回按平均分排序的热门景点。另外毕设演示前用 SQL 批量造数据保证每个用户至少评 3 个景点景点之间有一定重叠。4.2 MyBatis 映射字段与实体类属性对不上现象查询不报错但返回的对象字段全是 null。原因Mapper XML 里的resultMap列名和实体类属性名不一致比如数据库列是user_id实体类属性是userId但resultMap里没配column和property的映射。解决在mybatis-config.xml里开启mapUnderscoreToCamelCasetrue让下划线自动转驼峰。如果还不行手动检查resultMap的每一行。4.3 Spring 事务不生效插入评分后推荐没更新现象手动插了评论数据但推荐结果没变。原因Service 类没有加Transactional或者加了但 XML 里没开tx:annotation-driven。更隐蔽的情况是推荐方法内部调用了同类的方法Spring AOP 代理失效。解决确认spring-service.xml里有事务注解驱动推荐方法直接查数据库而不是走缓存。如果用了 MyBatis 二级缓存清一下缓存或关掉。4.4 中文乱码从 JSP 一路乱到数据库现象页面输入中文存进数据库变成问号。原因JSP 页面没设pageEncodingUTF-8或者 web.xml 里没配CharacterEncodingFilter或者数据库连接串没加characterEncodingutf8。解决三处都检查。JSP 头部加% page contentTypetext/html;charsetUTF-8 languagejava %web.xml 配过滤器jdbc.url加characterEncodingutf8。4.5 Tomcat 启动报 ClassNotFoundException 但依赖明明导入了现象IDEA 里依赖都在Tomcat 启动就是报类找不到。原因依赖没有打包到WEB-INF/lib下或者 IDEA 的 Artifact 配置里漏了库。解决在 Project Structure 的 Artifacts 里确认Available Elements中的依赖都双击加到了WEB-INF/lib下。或者直接用 Maven 的package命令打 war 包比 IDEA 的 Artifact 更可靠。5. 让推荐结果经得起答辩评分数据构造与算法参数调优5.1 用 SQL 批量构造有区分度的评分矩阵毕设演示最怕推荐结果“看起来像随机”。要让协同过滤跑出效果评分矩阵得有结构一部分用户口味相似一部分用户口味分散。我一般用 SQL 的INSERT ... SELECT配合随机函数造数据但随机太均匀反而没区分度。更好的做法是分三组用户第一组偏爱自然风光类景点ID 101-110第二组偏爱人文历史类111-120第三组随机。每组内用户的评分有重叠组间重叠少。-- 构造三组用户评分数据每组口味不同 -- 第一组用户 1-10偏爱景点 101-110 INSERT INTO comment (user_id, scenic_id, score, content, create_time) SELECT u.id, s.id, 4 (u.id s.id) % 2, 不错, NOW() FROM user u, scenic s WHERE u.id BETWEEN 1 AND 10 AND s.id BETWEEN 101 AND 110 AND (u.id s.id) % 3 ! 0; -- 制造部分缺失模拟真实稀疏 -- 第二组用户 11-20偏爱景点 111-120 INSERT INTO comment (user_id, scenic_id, score, content, create_time) SELECT u.id, s.id, 4 (u.id s.id) % 2, 很好, NOW() FROM user u, scenic s WHERE u.id BETWEEN 11 AND 20 AND s.id BETWEEN 111 AND 120 AND (u.id s.id) % 3 ! 0;这样造出来的矩阵用户 1 和用户 2 在 101-110 上有大量共同评分相似度高用户 1 和用户 11 几乎没有交集相似度低。推荐时用户 1 会优先收到 101-110 里他没评过的景点而不是 111-120 的。答辩时把这个逻辑讲清楚比说“用了协同过滤”有说服力得多。5.2 邻居数量 K 和推荐数量 N 的调参经验topN邻居数和recommendNum推荐数没有标准答案但有几个经验值。邻居数 K 一般取 10-20。K 太小比如 3推荐结果受个别用户影响大不稳定K 太大比如 50会把不相似的用户也拉进来推荐精度下降。推荐数 N 看页面展示位置首页取 5-8 个详情页“猜你喜欢”取 3-5 个。调参时可以用一个简单指标覆盖率。统计推荐结果里有多少景点是用户没看过但属于他偏好类别的。如果覆盖率低于 30%说明 K 太大或数据太稀疏如果高于 80%可能过拟合推荐来推荐去就那几个。我一般会在 Service 里加个日志把每次推荐的邻居 ID 和相似度打出来观察几轮再定参数。5.3 从 UserCF 切到 ItemCF 的改造思路如果答辩老师问“用户多了怎么办”UserCF 的瓶颈是用户数增长时相似度计算量平方级上升。这时候可以切到 ItemCF算景点之间的相似度推荐时看用户评过分的景点和哪些景点相似。改造点主要在buildUserItemMatrix之后把矩阵转置成景点-用户相似度计算逻辑不变只是遍历方向反过来。ItemCF 的另一个好处是景点数量通常比用户少矩阵更小计算更快。源码里如果预留了接口改起来就是换个实现类的事。从那以后我每次拿到 SSM 毕设源码都先跑通登录和列表页再单独把推荐模块拎出来用 SQL 造数据验证最后才调页面样式。这套顺序能避免在环境问题上耗太久也能让推荐算法在答辩时真正成为亮点。希望帮到你。本文还有配套的精品资源点击获取