简介：一套基于SSM框架与协同过滤算法实现的在线通用旅游平台毕业设计项目，面向计算机相关专业毕业生及Java入门至进阶学习者，可作为毕设、课程设计或期末大作业使用。项目包含前端、后端与MySQL完整源码，经严格调试可运行，并附数据库脚本、开发说明文档、论文、演示视频及代码注释。系统功能覆盖景点推荐管理、精选路线管理、用户信息管理、系统管理四大模块，其中景点推荐支持信息增删改查，精选路线可依据游客需求推荐合适出行路线，管理员可维护公告、简介、留言与站内新闻。资源包大小约106.17MB，主要文件类型包括java源码、sql脚本、word文档、mp4演示视频等，结构清晰便于直接部署学习。目前已有109人学习下载，适合需要完整可运行项目参考并希望理解SSM整合与协同过滤应用逻辑的读者。

1. 从毕设选题的痛点说起：SSM协同过滤旅游平台到底是什么

每到毕业设计的高峰期，做Java的同学都会在同样的路口打转：旅游网站、商城系统、预约平台这类题目铺天盖地，绝大多数是SSM写后台管理加一张MySQL表。这套基于SSM的协同过滤在线通用旅游平台，属于java毕业设计里比较少见带着算法亮点的选题——它不只是景点的增删改查，而是把用户的收藏行为和评分记录变成推荐系统的输入，让“热门景点”和“猜你喜欢”真正区分开。项目把前端页面、后端Java源码、MySQL完整脚本、开发说明文档和演示视频都打成了一个zip包，课程设计、期末大作业、毕设答辩三个场景都能直接用。需要说明白的是，这个项目解决的核心问题不是“做一个旅游网站”，而是“在旅游网站上把推荐做出来且能讲清楚原理”。

2. SSM架构与数据库表设计：协同过滤的数据从哪来

2.1 三层架构的请求链路：Controller、Service、Mapper怎么分工

SSM由Spring、Spring MVC、MyBatis三块拼成，项目里的大多数业务逻辑都遵循“控制器接请求、服务层算业务、Mapper查数据库”的单向链路。以景点推荐管理模块为例，用户在页面点“添加景点”，浏览器把POST请求送到Controller，Controller调Service里的方法做参数校验，Service再调Mapper接口操作MySQL表，结果一层层返回到页面。协同过滤推荐算法也挂在这条链路上，只是Service层不只查库，还要先计算用户之间的相似度。

从实际调试的角度看，SSM最需要先理解的是Spring容器负责管理Service和Mapper的实例，Spring MVC负责把URL映射到Controller方法，MyBatis负责把Mapper接口和XML里的SQL绑定起来。很多第一次跑SSM项目的人翻车，是因为没分清这三层各自的配置文件：spring-mvc.xml里配控制器扫描和视图解析器，applicationContext.xml里配数据源和Service扫描，mybatis-config.xml里配别名和Mapper映射。项目拿到手后，先别急着改代码，按这三个文件把依赖关系捋一遍，后面排查问题会快很多。

2.2 数据库表如何支撑协同过滤

这个项目的表设计并不复杂，但有几张表是推荐算法的“原料库”。用户信息表负责存放注册用户的基础资料，景点表存放名称、位置、价格、评分和分类信息，精选路线表把多个景点串成一条路线，还有一张收藏表和一张评分表专门记录用户对景点的行为。协同过滤需要的数据就是“哪个用户对哪个景点有过行为”，所以收藏表和评分表才是推荐模块真正依赖的核心。

用标准的建表SQL来看一下收藏表的结构：

CREATE TABLE `t_favorite` ( `id` int(11) NOT NULL AUTO_INCREMENT, `user_id` int(11) DEFAULT NULL, `scenic_id` int(11) DEFAULT NULL, `create_time` datetime DEFAULT NULL, PRIMARY KEY (`id`), KEY `idx_user` (`user_id`), KEY `idx_scenic` (`scenic_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这段SQL里最值得关注的是两个索引字段，user_id和scenic_id。推荐算法第一步是构建“用户对景点”的矩阵，本质上就是反复按用户ID分组查收藏记录，没有这两个索引，数据量过百条后查询会明显变慢。create_time字段虽然不参与相似度计算，但在二次开发时可以做时间衰减，后面第5章会提到。

景点表的字段设计也直接决定了推荐结果的美观度：

CREATE TABLE `t_scenic` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(100) NOT NULL, `location` varchar(255) DEFAULT NULL, `price` decimal(10,2) DEFAULT '0.00', `score` decimal(3,2) DEFAULT '5.00', `category` varchar(50) DEFAULT NULL, `cover` varchar(255) DEFAULT NULL, `status` int(1) DEFAULT '1', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

category字段在做“同类目补充推荐”时很有用，price字段可以用来做价格区间的兜底推荐。一个常见的做法是当协同过滤因为数据稀疏算不出结果时，先按category和price相近的景点补位，避免推荐区域空白，这个策略在答辩时也能讲成业务上的降级方案。

如果用表格来归纳表与推荐算法的关系，会更直观：

这里想强调一个容易被忽略的点：数据库里的score字段是景点自身的平均评分，和协同过滤里的用户评分是两个概念。景点平均评分只能做排序兜底，协同过滤算的是“用户之间的口味相似度”。如果开发说明文档里没有单独建评分表，也可以用收藏表加评论表的组合替代，只是代码里要把预处理逻辑写清楚，我一般会在Service层先统一封装成List结构再喂给算法。

3. 协同过滤推荐核心：相似度计算与推荐列表的完整实现

3.1 基于用户的协同过滤算法如何落到代码上

基于用户的协同过滤思路用一句话概括就是：找和你口味相似的人，看看他们喜欢什么你还没看过的东西。具体到旅游平台，就是先把用户收藏和评分的景点整理成一张稀疏矩阵，然后计算目标用户与其它用户的余弦相似度，选出最像的K个邻居，再拿邻居的偏好加权预测目标用户对未访问景点的兴趣分，最后按分数取TopN返回。

下面这个类是核心算法的精简实现，实际项目中可以直接把这段逻辑放进Service层：

public class UserBasedCF { private Map<Integer, Map<Integer, Double>> userItemMatrix = new HashMap<>(); private Set<Integer> allScenicIds = new HashSet<>(); public void loadData(List<RateRecord> records) { for (RateRecord r : records) { userItemMatrix .computeIfAbsent(r.getUserId(), k -> new HashMap<>()) .put(r.getScenicId(), r.getScore()); allScenicIds.add(r.getScenicId()); } } public List<Integer> recommend(int userId, int topN) { Map<Integer, Double> selfRatings = userItemMatrix.get(userId); if (selfRatings == null || selfRatings.isEmpty()) { return Collections.emptyList(); } // 第一步：计算目标用户与其他用户的余弦相似度 Map<Integer, Double> similarityMap = new HashMap<>(); for (Map.Entry<Integer, Map<Integer, Double>> entry : userItemMatrix.entrySet()) { if (entry.getKey().equals(userId)) continue; double sim = cosineSimilarity(selfRatings, entry.getValue()); if (sim > 0) similarityMap.put(entry.getKey(), sim); } // 第二步：选出相似度最高的K个邻居，K取5 List<Map.Entry<Integer, Double>> sortedUsers = new ArrayList<>(similarityMap.entrySet()); sortedUsers.sort((a, b) -> Double.compare(b.getValue(), a.getValue())); int k = Math.min(5, sortedUsers.size()); List<Integer> neighbors = new ArrayList<>(); for (int i = 0; i < k; i++) { neighbors.add(sortedUsers.get(i).getKey()); } // 第三步：加权汇总邻居的评分并归一化 Map<Integer, Double> scoreMap = new HashMap<>(); Map<Integer, Double> weightMap = new HashMap<>(); for (Integer neighbor : neighbors) { double sim = similarityMap.get(neighbor); Map<Integer, Double> neighborRatings = userItemMatrix.get(neighbor); for (Map.Entry<Integer, Double> item : neighborRatings.entrySet()) { if (selfRatings.containsKey(item.getKey())) continue; scoreMap.merge(item.getKey(), sim * item.getValue(), Double::sum); weightMap.merge(item.getKey(), sim, Double::sum); } } // 第四步：按加权平均分排序，取前topN个景点ID List<ScenicScore> list = new ArrayList<>(); for (Map.Entry<Integer, Double> e : scoreMap.entrySet()) { double weight = weightMap.getOrDefault(e.getKey(), 1.0); list.add(new ScenicScore(e.getKey(), e.getValue() / weight)); } list.sort((a, b) -> Double.compare(b.getScore(), a.getScore())); return list.stream() .limit(Math.min(topN, list.size())) .map(ScenicScore::getScenicId) .collect(Collectors.toList()); } private double cosineSimilarity(Map<Integer, Double> a, Map<Integer, Double> b) { // 只取两个用户都打过分的景点，取交集计算余弦值 double dot = 0, normA = 0, normB = 0; for (Map.Entry<Integer, Double> e : a.entrySet()) { normA += e.getValue() * e.getValue(); Double other = b.get(e.getKey()); if (other != null) dot += e.getValue() * other; } for (Double value : b.values()) { normB += value * value; } if (normA == 0 || normB == 0) return 0; return dot / (Math.sqrt(normA) * Math.sqrt(normB)); } }

这里的关键逻辑有四处。第一处是loadData方法把数据库里的原始记录转成“用户ID到景点评分映射”的嵌套结构，这一步决定了后续计算只能看到二维矩阵，看不到其它冗余字段，既减少内存占用也方便计算。第二处是cosineSimilarity方法，只取两个用户共同评分过的景点做点积，如果交集为空，相似度直接归零，这是一个必要的保护条件。第三处是K值的选择，代码里先用5做固定值，数据量大的项目可以改成构造方法传参，方便调优。第四处是加权平均的归一化处理，如果不除以weightMap里的相似度总和，评分高的邻居会主导结果，推荐会偏向单一用户。

3.2 Service层与Controller层如何把推荐结果拼装成页面数据

算法算出的只是景点ID的List，页面真正需要的是景点名称、图片、价格这些完整信息，所以Service层要做一次“算法结果转业务数据”的桥接。下面这段代码是推荐Service的常见写法：

@Service public class RecommendService { @Autowired private FavoriteMapper favoriteMapper; @Autowired private ScenicMapper scenicMapper; public List<ScenicVO> recommendScenic(Integer userId, Integer topN) { // 1. 拉取全量用户行为数据，构建协同过滤输入 List<RateRecord> records = favoriteMapper.selectAllForRecommend(); if (records.isEmpty()) { return scenicMapper.selectHotList(topN); } UserBasedCF cf = new UserBasedCF(); cf.loadData(records); List<Integer> scenicIds = cf.recommend(userId, topN); // 2. 冷启动兜底：用户无行为或算法结果为空时，按热度推荐 if (scenicIds.isEmpty()) { return scenicMapper.selectHotList(topN); } // 3. 按算法结果顺序返回景点详情 return scenicMapper.selectByIdsOrdered(scenicIds); } }

这段Service代码要注意两点。第一点，favoriteMapper.selectAllForRecommend()返回的是所有用户的收藏记录，如果线上数据量很大，这种全量查询需要改成按最近时间段过滤，比如只取最近90天的行为，既降低内存压力也符合“近期偏好”的业务直觉。第二点，selectByIdsOrdered这个方法在MyBatis里不能用普通的IN查询，因为IN查出来的顺序不保证和传入的ID顺序一致，需要用foreach循环配合CASE WHEN或者直接在Java层按顺序组装，否则推荐列表的顺序会被数据库打乱。

Controller层就相对轻量，主要是从Session里拿当前登录用户，然后调用Service：

@Controller @RequestMapping("/scenic") public class ScenicController { @Autowired private RecommendService recommendService; @RequestMapping("/recommend") @ResponseBody public Result recommend(HttpSession session) { User user = (User) session.getAttribute("loginUser"); int topN = 6; if (user == null) { return Result.success(recommendService.recommendScenic(null, topN)); } return Result.success(recommendService.recommendScenic(user.getId(), topN)); } }

这里的topN=6是给首页“猜你喜欢”区域准备的，6个卡片刚好排满两行。游客身份没有用户ID，Service层就会走热度兜底逻辑，这也解释了为什么未登录状态下看到的推荐区域和登录后的内容不同——不是Bug，是设计如此。答辩时如果能把这个细节讲出来，评委通常会认可你对业务场景的理解。

4. 部署运行与踩坑排查：从Maven构建到Tomcat上线最常见的四个问题

4.1 部署运行的基本步骤与参数检查

拿到项目后正确顺序是先初始化数据库，再启动后端，最后打开浏览器验证前端页面。数据库脚本直接用MySQL命令行导入，但要注意导入前建好一个空的数据库实例，否则表会散落在默认库里。后端是标准的Maven war包结构，通过IDEA打开后在右侧Maven面板里执行clean和package命令，打好的war包放到Tomcat的webapps目录下，启动Tomcat后用浏览器访问首页。

如果习惯用命令行操作，构建和部署的命令大致是这样的：

# 第一步：初始化数据库，travel_platform.sql是项目附带的脚本 mysql -uroot -p < travel_platform.sql # 第二步：跳过测试打包，避免JUnit测试干扰部署 mvn clean package -DskipTests # 第三步：把war包复制到Tomcat的webapps目录 cp target/travel-platform.war /path/to/tomcat/webapps/ # 第四步：启动Tomcat并持续观察日志 /path/to/tomcat/bin/startup.sh tail -f /path/to/tomcat/logs/catalina.out

这里最需要理解的是war包名直接决定访问路径。如果travel-platform.war被复制到webapps下，访问地址就是localhost:8080/travel-platform，如果改成ROOT.war则可以直接用localhost:8080访问。不少同学打开页面404，大概率是忘了这层关系。另外catalina.out日志是排错的第一现场，Tomcat启动时如果有Bean创建异常、数据源连接失败，StackOverflow都会打印在这个文件里，不要只看IDEA控制台。

4.2 启动时直接报数据库连接失败

现象：Tomcat启动过程中日志里出现“Communications link failure”或者“Access denied for user”，项目首页打不开，后台控制台一片红色异常。

原因：最常见的是jdbc.properties文件里的数据库地址、用户名或密码与本地MySQL环境不一致，也可能是MySQL服务根本没启动。其次是JDBC驱动版本和MySQL版本不匹配，比如数据库升级到8.0以上但驱动还停留在5.x，会报SSL连接或者CLIENT_PLUGIN_AUTH错误。

解决：先确认MySQL服务已启动，再用命令行手动登录一次验证账号密码。接着检查项目里jdbc.properties的配置，重点看url要写成jdbc:mysql://localhost:3306/数据库名?useUnicode=true&characterEncoding=UTF-8，如果本地MySQL是8.0以上，驱动和URL也要按8.0的写法调整。联网搜索时经常看到有人把“validateQuery”或者“testOnBorrow”的配置加进去，这套项目里不需要，但排查数据库连接时可以先去掉连接池的复杂参数，用最简配置定位问题。

4.3 页面能登录但跳转到空白页或404

现象：登录功能正常，数据库也能查到用户，但登录成功后跳转到一个空页面，或者页面的CSS、JS、图片全部变形。

原因：根因是Spring MVC的DispatcherServlet拦截了静态资源请求。配置了“/”作为url-pattern后，所有请求都会进Spring MVC，如果spring-mvc.xml没有声明静态资源放行规则，浏览器请求CSS、JS时就会走到控制器映射里找不到处理器，结果是404。另一个常见原因是视图解析器的前缀后缀配置不对，返回的JSP路径拼出来是/WEB-INF/views/xxx.jsp，但实际页面不在这个目录下。

解决：在spring-mvc.xml里补充静态资源映射配置，下面这段是标准写法：

<mvc:resources mapping="/static/**" location="/static/"/> <mvc:annotation-driven/>

如果项目里静态资源放在webapp根目录的static文件夹下，这段配置就能让浏览器正常拿到CSS和JS。JSP路径的问题则要检查视图解析器的prefix和suffix属性，例如：

<bean class="org.springframework.web.servlet.view.InternalResourceViewResolver"> <property name="prefix" value="/WEB-INF/views/"/> <property name="suffix" value=".jsp"/> </bean>

这段配置说明Controller返回“scenic/list”时，实际加载的是/WEB-INF/views/scenic/list.jsp。在排查过程中我一般会先在浏览器开发者工具里看Network面板，如果HTML能加载但CSS返回404，就是静态资源放行问题；如果HTML本身都没出来，再往视图解析器方向查。

4.4 推荐列表一直为空或显示的景点不是推荐的

现象：看到“猜你喜欢”区域，但里面要么是空白，要么和热门景点排序完全一样，没有个性化差别。

原因：协同过滤的冷启动和数据稀疏问题。新建的用户没有任何收藏和评分记录，从用户-景点矩阵里找不到这个用户的行，算法返回空列表。代码里虽然有热度兜底，但如果兜底逻辑写成了“查到全部景点再按ID排序”，推荐区域看起来就会像是随机景点而不是个性化结果。

解决：为了让演示效果好，需要在库里模拟一部分用户行为数据。管理员账号注册后去收藏几个景点，再换一个普通用户注册登录，让两个用户之间有部分重叠的收藏记录。数据准备充分后，推荐结果才会有明显差异。另外还要检查FavoriteMapper的selectAllForRecommend是否能查到数据，这个简单SQL如果在窗口里能跑出结果，问题就不在数据层。

4.5 JSP页面中文乱码

现象：登录后页面上的用户名、景点名称、路线描述都是乱码，但数据库里看数据正常。

原因：字符编码链路上有三处可能不一致。JSP页面本身不是UTF-8编码、MySQL连接的URL缺少characterEncoding参数、Tomcat的Connector没有设置URIEncoding。这三处只要有一处断了，中文就会显示成“ç”或“??”。

解决：JSP文件开头加page指令，MySQL的JDBC URL里带编码参数，Tomcat的server.xml里给Connector增加URIEncoding="UTF-8"。这是Web开发里典型的编码三件套：

<Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" URIEncoding="UTF-8"/>

排查顺序是先看JSP页面文件编码，再看数据库脚本导入时的会话编码，最后才是Tomcat连接器。很多情况下问题出在导入SQL脚本时用的是命令行，Windows命令行默认GBK编码，导入的UTF-8文本变成了乱码，解决办法是用Navicat或者通过sql文件头加SET NAMES utf8mb4来强制指定。

5. 答辩前二次验证与展示技巧：让算法效果能讲出真实数据

到了答辩前一周，很多人还在反复跑页面截图，但其实重点应该放在验证推荐效果和准备讲解逻辑上。验证方法不需要多复杂，注册三个测试账号，分别给它们制造不同的收藏偏好，比如A账号都收藏山水类景点，B账号都收藏古城类景点，C账号同时收藏了山水类和一处古城。登录A账号看推荐列表里是否有C收藏的那处古城景点，如果有，说明相似用户成功传递了偏好；如果没有，说明算法中的相似度计算或者邻居选取有数据问题。这个小实验花不了半小时，但能成为答辩现场最有说服力的证据。

如果想让推荐效果更贴近真实业务，我一般会做一个扩展改动：给相似度加上时间衰减因子。具体做法是把收藏表的create_time变成权重系数，近期收藏比长期收藏在计算时赋更高权重，公式上就是在cosineSimilarity的点积部分乘一个衰减因子。这个改动不算大，但答辩时可以讲成“考虑用户兴趣漂移的改进”，是个低成本高收益的亮点。

从代码讲解的技巧来说，不要从Controller开始讲，评委更想听到的是数据流：登录取到用户ID，行为表里拉出所有收藏记录，拼成稀疏矩阵，计算余弦相似度，选TopK邻居，加权平均，得到TopN结果。这一串如果能在电脑上边翻代码边讲，三分钟就能讲完，随后留时间回答“为什么不优先看景点评分”这类追问。我的习惯是回答这类问题时强调评分是物品维度的静态属性，协同过滤解决的是用户维度偏好匹配，两者是不同层面的信号。

至于路线推荐模块，它是精选路线管理的一个延伸点。目前的实现更偏重管理员配置路线，真正基于协同过滤做路线推荐需要把路线和景点的关系表加进来，构建“用户-路线”矩阵。如果剩余时间充足，把路线维度加进推荐列表里，项目从“景点推荐”升级成“路线推荐”，内容会更饱满。

从那以后我每次拿到这类带算法的SSM项目，都会强制走一遍“看配置文件、建库导数据、注册两个用户制造行为差异、再跑推荐页”的完整流程，不再急着改界面样式。跑通只是第一步，能把推荐结果和用户行为对上，才算真正把项目吃透了。希望这份拆解能帮你在毕设答辩前少走弯路，也欢迎你按这套流程去检验下载的资源包里每一个模块到底靠不靠得住。

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