简介这是一份面向计算机专业学生与Java Web开发学习者的旅游景点个性化推荐系统毕业设计资料以JSPServlet技术栈实现重点解决景点信息管理与个性化推荐问题。系统采用B/S三层架构客户端基于Web浏览器与协同过滤算法服务器端基于JSP和Servlet数据源基于关系型数据库涵盖用户管理、分类展示景点、推荐引擎、景点详情及首页轮播等五大模块支持夏季旅游、文化旅游、高原精品线路、亲子旅游等分类展示与个性化推荐。资源包为1个docx文档约1.35MB内容为完整毕业论文包含摘要、系统开发关键技术、需求分析、协同过滤算法说明及系统实现等章节结构完整、论述规范。目前已有99人浏览学习适合作为Java Web课程设计、毕业设计选题参考也可帮助读者理解协同过滤推荐算法在旅游场景中的落地思路与三层框架搭建方法。1. 从一份 JSP 旅游推荐论文包说起它到底能跑出什么如果你手头正缺一个能写进简历、能当毕业设计底稿、又能真跑起来的 Java Web 项目这份「旅游景点个性化推荐论文 JSP 源码」大概率能省掉你两周的翻车时间。它不是那种只有几张静态页面的空壳而是把协同过滤算法、用户行为采集、景点分类展示、旅游笔记这几块串成了一条完整链路前台用 JSP 渲染景点轮播和推荐位后台用 Servlet 接请求中间夹着一层基于用户的协同过滤做个性化推荐数据落在关系型数据库里。适合三类人一是正在做旅游推荐方向毕业设计的同学二是想补一个「算法 Web 全栈」实战案例的 Java 新手三是需要快速搭一个推荐系统 Demo 去验证产品思路的开发者。下面我按「先讲清它怎么运转再带你把它跑起来最后把坑一个个填掉」的顺序拆开说。2. 三层架构与协同过滤这套推荐引擎的骨架长什么样2.1 MVC 三层怎么分为什么 JSP 项目必须这么切这套系统用的是经典 MVC 三层Model 层由 JavaBean 承载业务数据和数据库操作View 层是 JSP 页面负责动态渲染Controller 层用 Servlet 接住浏览器请求、调度业务、决定跳哪个页面。很多人写 JSP 项目容易写成「JSP 里塞满 Java 代码」页面一复杂就变成一锅粥改一个查询条件要翻三个文件。这套源码把职责切开了你改推荐逻辑只动 Servlet 和 Bean改样式只动 JSP互不干扰。具体到目录结构常见做法是src下按bean、dao、servlet、util分包WebContent下放jsp、css、js、images。Servlet 在web.xml或注解里配好映射路径JSP 通过 EL 表达式和 JSTL 标签取后端传过来的 List不再写% %脚本片段。这样做的直接好处是推荐结果变了页面模板不用动页面改版了算法不用碰。提示如果你拿到的源码里 JSP 还有大量% ... %脚本先别急着重构能跑通再谈优化毕业设计阶段稳定优先。2.2 基于用户的协同过滤在这套系统里怎么落地协同过滤分两大类基于用户的和基于物品的。这套系统用的是基于用户的UserCF逻辑不复杂把每个用户对景点的喜好点击、收藏、打分当成一个向量算用户之间的相似度找到和你口味最像的一批人把他们喜欢但你没看过的景点推给你。相似度计算常用余弦相似度或皮尔逊相关系数。余弦相似度对评分尺度不敏感实现也简单源码里大概率用的是它。公式不展开你只要记住两个用户共同喜好的景点越多、评分越接近相似度越高。系统里用户对景点的「喜好」通过喜好表记录每点一次、收藏一次关联次数加一这个次数就是隐式评分的来源。推荐引擎内部拆成三块采集游客信息和喜好数据、对喜好做处理算出每类游客的 Top 景点、给新用户归类后按类推荐。新用户注册时选的旅游偏好夏季旅游、文化旅游、高原线路等就是冷启动的分类依据避免了一上来没行为数据就推不出来的尴尬。2.3 数据库三张核心表字段和关系一次说清系统数据库里最关键的是用户表、景点表、景点喜好表。用户表存账号密码和基本信息景点表存线路名称、适合季节、累计游客数、推荐理由、地点、分类喜好表是用户和景点的多对多关联记录喜好次数。表名关键字段作用userid、type、name、password、tel、email存用户身份与登录信息type 区分管理员和普通用户scenicid、name、time、count、reason、place、category存景点基础信息category 支撑分类展示favoriteuserId、tourId、count记录用户对景点的喜好次数是协同过滤的数据源喜好表里的count字段很关键它不是简单的 0/1 标记而是累加值。用户反复查看同一个景点count 变大说明偏好更强算相似度时权重更高。这个设计比单纯记录「喜欢/不喜欢」要细推荐结果也更贴近真实兴趣。2.4 推荐引擎的数据流从点击到推荐位一次完整的推荐请求是这样走的用户在景点详情页点了收藏前端发请求到 ServletServlet 调 DAO 往喜好表插一条记录或更新 count同时把这次行为写进用户行为日志。当用户回到首页或刷新推荐位时Servlet 取出该用户的喜好列表调协同过滤工具类算出相似用户集合再取相似用户喜欢而当前用户没看过的景点按预测喜好度排序取 Top N 返回给 JSP 渲染。冷启动用户没有喜好记录系统退化成按景点热度推荐也就是按景点表里的累计游客数排序。这个降级策略很实用保证首页永远有内容可推不会出现空白推荐位。3. 把项目跑起来环境、建库、部署一条龙3.1 环境版本怎么选别在这步翻车这套项目是 JSP Servlet 技术栈不是 Spring Boot所以别用 JDK 17 往上硬套容易遇到模块化报错。稳妥组合是 JDK 8 或 11、Tomcat 8.5 或 9、MySQL 5.7 或 8.0。IDE 用 Eclipse 或 IntelliJ IDEA 都行IDEA 需要装 Web 插件并配好 Tomcat 运行配置。数据库连接一般写在db.properties或工具类里驱动用com.mysql.cj.jdbc.DriverMySQL 8或com.mysql.jdbc.DriverMySQL 5。连接串记得加useSSLfalseserverTimezoneAsia/ShanghaicharacterEncodingutf8否则中文乱码和时区报错会轮番找你麻烦。# 建库并导入初始数据假设源码里带了 travel.sql mysql -u root -p -e CREATE DATABASE travel_db DEFAULT CHARACTER SET utf8mb4; mysql -u root -p travel_db travel.sql第一行建库时指定utf8mb4是为了让景点名称、旅游笔记里的中文和特殊符号都能正常存。第二行把源码附带的 SQL 文件导进去表结构和初始景点数据就都有了。如果 SQL 文件里没有建库语句先手动建库再导入否则会报「No database selected」。3.2 数据库连接配置与常见参数连接池不是必须的但建议加上否则每次请求都新建连接压测时数据库很快扛不住。源码如果用的是原生 JDBC你可以手动引入 Druid 或 C3P0改造成本不高。# db.properties 示例 jdbc.drivercom.mysql.cj.jdbc.Driver jdbc.urljdbc:mysql://localhost:3306/travel_db?useSSLfalseserverTimezoneAsia/ShanghaicharacterEncodingutf8 jdbc.usernameroot jdbc.password你的密码serverTimezone不配的话MySQL 8 驱动会抛时区异常characterEncodingutf8保证中文不乱码useSSLfalse是本地开发省去证书配置。生产环境要把 SSL 打开但毕业设计本地跑关掉更省事。3.3 部署到 Tomcat 并验证首页把项目打成 war 包丢进 Tomcat 的webapps目录或者直接在 IDE 里配 Tomcat 运行。启动后访问http://localhost:8080/项目名/能看到首页轮播和推荐位就算成功一半。# 命令行部署方式 cp travel-recommend.war $TOMCAT_HOME/webapps/ $TOMCAT_HOME/bin/startup.sh tail -f $TOMCAT_HOME/logs/catalina.outcp把 war 包复制到部署目录Tomcat 启动时会自动解压。tail -f盯日志是排查启动失败最快的手段常见错误无非是数据库连不上、驱动没找到、端口被占。看到Server startup in xxx ms基本就稳了。3.4 注册登录与推荐链路自测部署成功后先注册一个账号注册时选好旅游偏好分类然后登录。接着去景点详情页点几次收藏再回首页看推荐位有没有变化。如果推荐位从「热门景点」变成了和你收藏相似的景点说明协同过滤链路通了。自测顺序建议注册 → 登录 → 浏览分类 → 收藏景点 → 回首页看推荐 → 写一条旅游笔记。每一步都对应一个模块哪步断了就查对应的 Servlet 和 DAO。推荐没变化先别怀疑算法大概率是喜好数据没写进库或者相似度计算时用户数太少少于 2 个用户算不出相似邻居。4. 协同过滤调参相似度、邻居数、推荐数怎么定4.1 相似度阈值与邻居数量协同过滤有两个关键参数相似度阈值和邻居数 K。阈值太低什么人都算相似推荐变成大杂烩阈值太高找不到邻居推荐退化成热门榜。K 太小推荐覆盖面窄K 太大计算量上去且噪声增多。常见做法是 K 取 10 到 30相似度阈值取 0.2 到 0.5具体看数据量。用户和景点都只有几十条时K 取 5 到 10 就够。你可以在工具类里把这两个值抽成常量方便调。// 协同过滤核心参数放在常量类里便于调整 public class CfConfig { public static final int NEIGHBOR_K 10; // 相似邻居数量 public static final double SIM_THRESHOLD 0.3; // 相似度下限 public static final int RECOMMEND_N 8; // 推荐位展示数量 }NEIGHBOR_K控制参与推荐的相似用户数SIM_THRESHOLD过滤掉不相似的邻居RECOMMEND_N决定首页推荐位放几个景点。改完这三个值重新部署观察推荐结果的变化就能直观感受参数的影响。4.2 冷启动与数据稀疏的应对新用户没行为、新景点没人看是协同过滤的两个老大难。这套系统的冷启动靠注册时选的偏好分类兜底把用户先归到某一类按类内热门推荐。数据稀疏则靠喜好表的 count 累加缓解用户哪怕只点了一次也算一条有效信号。如果数据实在太少可以引入基于内容的推荐做补充按景点分类、适合季节和用户偏好做匹配和协同过滤结果加权融合。源码里不一定有这层但你可以自己加思路是给每个景点打标签用户偏好也转成标签向量算标签重合度。4.3 推荐结果怎么验证有没有效果没有线上流量就用离线指标准确率、召回率、覆盖率。把用户行为按时间切前 80% 当训练集后 20% 当测试集看推荐列表命中测试集的比例。更简单的方法是人工抽查找几个兴趣明显的用户看推给他们的景点是否对路。注意小数据集上离线指标波动很大别为了刷高准确率把推荐数压到一两个那样覆盖率惨不忍睹实际体验反而差。5. 避坑与排查这套 JSP 推荐系统最容易翻车的五个地方5.1 中文乱码现象是景点名变问号原因是编码链没统一现象数据库里中文正常页面上显示成???或乱码。原因JSP 页面、Servlet 请求、数据库连接三处编码不一致。解决JSP 头部加% page contentTypetext/html;charsetUTF-8 %Servlet 里request.setCharacterEncoding(UTF-8)和response.setContentType(text/html;charsetUTF-8)数据库连接串带characterEncodingutf8建库用utf8mb4。四处对齐乱码基本绝迹。5.2 推荐位空白现象是首页推荐区没内容原因是冷启动没兜底现象新用户登录后推荐位一片空白。原因协同过滤找不到相似邻居又没写热门降级逻辑。解决在推荐 Servlet 里加判断如果协同过滤返回空列表就查景点表按累计游客数倒序取前 N 个。这个兜底必须有否则新用户第一眼就是空页面体验直接崩。5.3 数据库连接泄漏现象是跑一会儿就报连接超时原因是没关资源现象系统跑一段时间后报Too many connections。原因DAO 里 Connection、Statement、ResultSet 用完没关。解决用 try-with-resources 或在 finally 里逐个 close最好引入连接池统一管理。JSP 项目里这种泄漏特别常见因为很多人图省事不写 finally。5.4 相似度算成 NaN现象是推荐报错或结果异常原因是除零现象日志里出现NaN或推荐结果乱序。原因两个用户没有共同喜好景点余弦相似度分母为零。解决算相似度前先判断共同喜好集合是否为空为空直接跳过该用户对不参与推荐。这个判断不加数据一稀疏就翻车。5.5 Tomcat 启动报 404现象是访问项目路径找不到页面原因是上下文路径不对现象Tomcat 启动成功但访问http://localhost:8080/是 404。原因项目上下文路径不是根路径或者 war 包名和访问路径不一致。解决访问时带上项目名如http://localhost:8080/travel-recommend/或者在 Tomcat 的server.xml里配 Context 把路径映射到根。别小看这一步新手卡在这里半小时很常见。6. 进阶玩法把推荐结果做成可解释的顺带验证算法6.1 给推荐加一句「为什么推给你」纯算法推荐对用户是黑匣子加一句解释能大幅提升可信度。做法很简单推荐时记录是哪个相似用户贡献的展示时写成「和你口味相似的用户也喜欢」。在推荐结果对象里加一个reason字段Servlet 拼好传给 JSP。// 推荐结果封装带上推荐理由 public class RecommendItem { private Scenic scenic; private double score; private String reason; // 例如相似用户也喜欢 / 同类热门 // getter、setter 省略 }score是预测喜好度用来排序reason是给用户看的解释。JSP 里在景点卡片下方渲染这行小字用户感知立刻不一样。这个改动成本极低但答辩时是加分项。6.2 用 A/B 对比验证推荐是否真的有用想证明推荐有效最土也最靠谱的办法是 A/B 对比一半用户走协同过滤推荐一半走热门推荐统计两组的点击率和收藏率。在用户表加一个group字段标记分组推荐 Servlet 按分组走不同逻辑埋点记录点击。指标热门推荐组协同过滤组说明点击率基准对比值推荐位点击次数 / 曝光次数收藏率基准对比值收藏次数 / 点击次数人均浏览景点数基准对比值反映推荐是否拓宽了探索面数据量小的时候差异可能不显著但趋势能看出来。答辩时拿这张表说话比空谈「算法提升了体验」有说服力得多。6.3 我踩过的那个坑有次我图省事把相似度计算放在 JSP 页面里直接算结果页面加载慢到怀疑人生而且每次刷新都重算一遍数据库连接数飙升。后来把计算挪到 Servlet加了一层内存缓存相同用户的推荐结果缓存五分钟性能立刻正常。从那以后我每次做推荐类项目都强制把算法计算和页面渲染彻底分开缓存该加就加绝不让 JSP 碰业务逻辑。希望帮到你。本文还有配套的精品资源点击获取 JSP旅游推荐系统实战：协同过滤算法与毕业设计源码解析
简介这是一份面向计算机专业学生与Java Web开发学习者的旅游景点个性化推荐系统毕业设计资料以JSPServlet技术栈实现重点解决景点信息管理与个性化推荐问题。系统采用B/S三层架构客户端基于Web浏览器与协同过滤算法服务器端基于JSP和Servlet数据源基于关系型数据库涵盖用户管理、分类展示景点、推荐引擎、景点详情及首页轮播等五大模块支持夏季旅游、文化旅游、高原精品线路、亲子旅游等分类展示与个性化推荐。资源包为1个docx文档约1.35MB内容为完整毕业论文包含摘要、系统开发关键技术、需求分析、协同过滤算法说明及系统实现等章节结构完整、论述规范。目前已有99人浏览学习适合作为Java Web课程设计、毕业设计选题参考也可帮助读者理解协同过滤推荐算法在旅游场景中的落地思路与三层框架搭建方法。1. 从一份 JSP 旅游推荐论文包说起它到底能跑出什么如果你手头正缺一个能写进简历、能当毕业设计底稿、又能真跑起来的 Java Web 项目这份「旅游景点个性化推荐论文 JSP 源码」大概率能省掉你两周的翻车时间。它不是那种只有几张静态页面的空壳而是把协同过滤算法、用户行为采集、景点分类展示、旅游笔记这几块串成了一条完整链路前台用 JSP 渲染景点轮播和推荐位后台用 Servlet 接请求中间夹着一层基于用户的协同过滤做个性化推荐数据落在关系型数据库里。适合三类人一是正在做旅游推荐方向毕业设计的同学二是想补一个「算法 Web 全栈」实战案例的 Java 新手三是需要快速搭一个推荐系统 Demo 去验证产品思路的开发者。下面我按「先讲清它怎么运转再带你把它跑起来最后把坑一个个填掉」的顺序拆开说。2. 三层架构与协同过滤这套推荐引擎的骨架长什么样2.1 MVC 三层怎么分为什么 JSP 项目必须这么切这套系统用的是经典 MVC 三层Model 层由 JavaBean 承载业务数据和数据库操作View 层是 JSP 页面负责动态渲染Controller 层用 Servlet 接住浏览器请求、调度业务、决定跳哪个页面。很多人写 JSP 项目容易写成「JSP 里塞满 Java 代码」页面一复杂就变成一锅粥改一个查询条件要翻三个文件。这套源码把职责切开了你改推荐逻辑只动 Servlet 和 Bean改样式只动 JSP互不干扰。具体到目录结构常见做法是src下按bean、dao、servlet、util分包WebContent下放jsp、css、js、images。Servlet 在web.xml或注解里配好映射路径JSP 通过 EL 表达式和 JSTL 标签取后端传过来的 List不再写% %脚本片段。这样做的直接好处是推荐结果变了页面模板不用动页面改版了算法不用碰。提示如果你拿到的源码里 JSP 还有大量% ... %脚本先别急着重构能跑通再谈优化毕业设计阶段稳定优先。2.2 基于用户的协同过滤在这套系统里怎么落地协同过滤分两大类基于用户的和基于物品的。这套系统用的是基于用户的UserCF逻辑不复杂把每个用户对景点的喜好点击、收藏、打分当成一个向量算用户之间的相似度找到和你口味最像的一批人把他们喜欢但你没看过的景点推给你。相似度计算常用余弦相似度或皮尔逊相关系数。余弦相似度对评分尺度不敏感实现也简单源码里大概率用的是它。公式不展开你只要记住两个用户共同喜好的景点越多、评分越接近相似度越高。系统里用户对景点的「喜好」通过喜好表记录每点一次、收藏一次关联次数加一这个次数就是隐式评分的来源。推荐引擎内部拆成三块采集游客信息和喜好数据、对喜好做处理算出每类游客的 Top 景点、给新用户归类后按类推荐。新用户注册时选的旅游偏好夏季旅游、文化旅游、高原线路等就是冷启动的分类依据避免了一上来没行为数据就推不出来的尴尬。2.3 数据库三张核心表字段和关系一次说清系统数据库里最关键的是用户表、景点表、景点喜好表。用户表存账号密码和基本信息景点表存线路名称、适合季节、累计游客数、推荐理由、地点、分类喜好表是用户和景点的多对多关联记录喜好次数。表名关键字段作用userid、type、name、password、tel、email存用户身份与登录信息type 区分管理员和普通用户scenicid、name、time、count、reason、place、category存景点基础信息category 支撑分类展示favoriteuserId、tourId、count记录用户对景点的喜好次数是协同过滤的数据源喜好表里的count字段很关键它不是简单的 0/1 标记而是累加值。用户反复查看同一个景点count 变大说明偏好更强算相似度时权重更高。这个设计比单纯记录「喜欢/不喜欢」要细推荐结果也更贴近真实兴趣。2.4 推荐引擎的数据流从点击到推荐位一次完整的推荐请求是这样走的用户在景点详情页点了收藏前端发请求到 ServletServlet 调 DAO 往喜好表插一条记录或更新 count同时把这次行为写进用户行为日志。当用户回到首页或刷新推荐位时Servlet 取出该用户的喜好列表调协同过滤工具类算出相似用户集合再取相似用户喜欢而当前用户没看过的景点按预测喜好度排序取 Top N 返回给 JSP 渲染。冷启动用户没有喜好记录系统退化成按景点热度推荐也就是按景点表里的累计游客数排序。这个降级策略很实用保证首页永远有内容可推不会出现空白推荐位。3. 把项目跑起来环境、建库、部署一条龙3.1 环境版本怎么选别在这步翻车这套项目是 JSP Servlet 技术栈不是 Spring Boot所以别用 JDK 17 往上硬套容易遇到模块化报错。稳妥组合是 JDK 8 或 11、Tomcat 8.5 或 9、MySQL 5.7 或 8.0。IDE 用 Eclipse 或 IntelliJ IDEA 都行IDEA 需要装 Web 插件并配好 Tomcat 运行配置。数据库连接一般写在db.properties或工具类里驱动用com.mysql.cj.jdbc.DriverMySQL 8或com.mysql.jdbc.DriverMySQL 5。连接串记得加useSSLfalseserverTimezoneAsia/ShanghaicharacterEncodingutf8否则中文乱码和时区报错会轮番找你麻烦。# 建库并导入初始数据假设源码里带了 travel.sql mysql -u root -p -e CREATE DATABASE travel_db DEFAULT CHARACTER SET utf8mb4; mysql -u root -p travel_db travel.sql第一行建库时指定utf8mb4是为了让景点名称、旅游笔记里的中文和特殊符号都能正常存。第二行把源码附带的 SQL 文件导进去表结构和初始景点数据就都有了。如果 SQL 文件里没有建库语句先手动建库再导入否则会报「No database selected」。3.2 数据库连接配置与常见参数连接池不是必须的但建议加上否则每次请求都新建连接压测时数据库很快扛不住。源码如果用的是原生 JDBC你可以手动引入 Druid 或 C3P0改造成本不高。# db.properties 示例 jdbc.drivercom.mysql.cj.jdbc.Driver jdbc.urljdbc:mysql://localhost:3306/travel_db?useSSLfalseserverTimezoneAsia/ShanghaicharacterEncodingutf8 jdbc.usernameroot jdbc.password你的密码serverTimezone不配的话MySQL 8 驱动会抛时区异常characterEncodingutf8保证中文不乱码useSSLfalse是本地开发省去证书配置。生产环境要把 SSL 打开但毕业设计本地跑关掉更省事。3.3 部署到 Tomcat 并验证首页把项目打成 war 包丢进 Tomcat 的webapps目录或者直接在 IDE 里配 Tomcat 运行。启动后访问http://localhost:8080/项目名/能看到首页轮播和推荐位就算成功一半。# 命令行部署方式 cp travel-recommend.war $TOMCAT_HOME/webapps/ $TOMCAT_HOME/bin/startup.sh tail -f $TOMCAT_HOME/logs/catalina.outcp把 war 包复制到部署目录Tomcat 启动时会自动解压。tail -f盯日志是排查启动失败最快的手段常见错误无非是数据库连不上、驱动没找到、端口被占。看到Server startup in xxx ms基本就稳了。3.4 注册登录与推荐链路自测部署成功后先注册一个账号注册时选好旅游偏好分类然后登录。接着去景点详情页点几次收藏再回首页看推荐位有没有变化。如果推荐位从「热门景点」变成了和你收藏相似的景点说明协同过滤链路通了。自测顺序建议注册 → 登录 → 浏览分类 → 收藏景点 → 回首页看推荐 → 写一条旅游笔记。每一步都对应一个模块哪步断了就查对应的 Servlet 和 DAO。推荐没变化先别怀疑算法大概率是喜好数据没写进库或者相似度计算时用户数太少少于 2 个用户算不出相似邻居。4. 协同过滤调参相似度、邻居数、推荐数怎么定4.1 相似度阈值与邻居数量协同过滤有两个关键参数相似度阈值和邻居数 K。阈值太低什么人都算相似推荐变成大杂烩阈值太高找不到邻居推荐退化成热门榜。K 太小推荐覆盖面窄K 太大计算量上去且噪声增多。常见做法是 K 取 10 到 30相似度阈值取 0.2 到 0.5具体看数据量。用户和景点都只有几十条时K 取 5 到 10 就够。你可以在工具类里把这两个值抽成常量方便调。// 协同过滤核心参数放在常量类里便于调整 public class CfConfig { public static final int NEIGHBOR_K 10; // 相似邻居数量 public static final double SIM_THRESHOLD 0.3; // 相似度下限 public static final int RECOMMEND_N 8; // 推荐位展示数量 }NEIGHBOR_K控制参与推荐的相似用户数SIM_THRESHOLD过滤掉不相似的邻居RECOMMEND_N决定首页推荐位放几个景点。改完这三个值重新部署观察推荐结果的变化就能直观感受参数的影响。4.2 冷启动与数据稀疏的应对新用户没行为、新景点没人看是协同过滤的两个老大难。这套系统的冷启动靠注册时选的偏好分类兜底把用户先归到某一类按类内热门推荐。数据稀疏则靠喜好表的 count 累加缓解用户哪怕只点了一次也算一条有效信号。如果数据实在太少可以引入基于内容的推荐做补充按景点分类、适合季节和用户偏好做匹配和协同过滤结果加权融合。源码里不一定有这层但你可以自己加思路是给每个景点打标签用户偏好也转成标签向量算标签重合度。4.3 推荐结果怎么验证有没有效果没有线上流量就用离线指标准确率、召回率、覆盖率。把用户行为按时间切前 80% 当训练集后 20% 当测试集看推荐列表命中测试集的比例。更简单的方法是人工抽查找几个兴趣明显的用户看推给他们的景点是否对路。注意小数据集上离线指标波动很大别为了刷高准确率把推荐数压到一两个那样覆盖率惨不忍睹实际体验反而差。5. 避坑与排查这套 JSP 推荐系统最容易翻车的五个地方5.1 中文乱码现象是景点名变问号原因是编码链没统一现象数据库里中文正常页面上显示成???或乱码。原因JSP 页面、Servlet 请求、数据库连接三处编码不一致。解决JSP 头部加% page contentTypetext/html;charsetUTF-8 %Servlet 里request.setCharacterEncoding(UTF-8)和response.setContentType(text/html;charsetUTF-8)数据库连接串带characterEncodingutf8建库用utf8mb4。四处对齐乱码基本绝迹。5.2 推荐位空白现象是首页推荐区没内容原因是冷启动没兜底现象新用户登录后推荐位一片空白。原因协同过滤找不到相似邻居又没写热门降级逻辑。解决在推荐 Servlet 里加判断如果协同过滤返回空列表就查景点表按累计游客数倒序取前 N 个。这个兜底必须有否则新用户第一眼就是空页面体验直接崩。5.3 数据库连接泄漏现象是跑一会儿就报连接超时原因是没关资源现象系统跑一段时间后报Too many connections。原因DAO 里 Connection、Statement、ResultSet 用完没关。解决用 try-with-resources 或在 finally 里逐个 close最好引入连接池统一管理。JSP 项目里这种泄漏特别常见因为很多人图省事不写 finally。5.4 相似度算成 NaN现象是推荐报错或结果异常原因是除零现象日志里出现NaN或推荐结果乱序。原因两个用户没有共同喜好景点余弦相似度分母为零。解决算相似度前先判断共同喜好集合是否为空为空直接跳过该用户对不参与推荐。这个判断不加数据一稀疏就翻车。5.5 Tomcat 启动报 404现象是访问项目路径找不到页面原因是上下文路径不对现象Tomcat 启动成功但访问http://localhost:8080/是 404。原因项目上下文路径不是根路径或者 war 包名和访问路径不一致。解决访问时带上项目名如http://localhost:8080/travel-recommend/或者在 Tomcat 的server.xml里配 Context 把路径映射到根。别小看这一步新手卡在这里半小时很常见。6. 进阶玩法把推荐结果做成可解释的顺带验证算法6.1 给推荐加一句「为什么推给你」纯算法推荐对用户是黑匣子加一句解释能大幅提升可信度。做法很简单推荐时记录是哪个相似用户贡献的展示时写成「和你口味相似的用户也喜欢」。在推荐结果对象里加一个reason字段Servlet 拼好传给 JSP。// 推荐结果封装带上推荐理由 public class RecommendItem { private Scenic scenic; private double score; private String reason; // 例如相似用户也喜欢 / 同类热门 // getter、setter 省略 }score是预测喜好度用来排序reason是给用户看的解释。JSP 里在景点卡片下方渲染这行小字用户感知立刻不一样。这个改动成本极低但答辩时是加分项。6.2 用 A/B 对比验证推荐是否真的有用想证明推荐有效最土也最靠谱的办法是 A/B 对比一半用户走协同过滤推荐一半走热门推荐统计两组的点击率和收藏率。在用户表加一个group字段标记分组推荐 Servlet 按分组走不同逻辑埋点记录点击。指标热门推荐组协同过滤组说明点击率基准对比值推荐位点击次数 / 曝光次数收藏率基准对比值收藏次数 / 点击次数人均浏览景点数基准对比值反映推荐是否拓宽了探索面数据量小的时候差异可能不显著但趋势能看出来。答辩时拿这张表说话比空谈「算法提升了体验」有说服力得多。6.3 我踩过的那个坑有次我图省事把相似度计算放在 JSP 页面里直接算结果页面加载慢到怀疑人生而且每次刷新都重算一遍数据库连接数飙升。后来把计算挪到 Servlet加了一层内存缓存相同用户的推荐结果缓存五分钟性能立刻正常。从那以后我每次做推荐类项目都强制把算法计算和页面渲染彻底分开缓存该加就加绝不让 JSP 碰业务逻辑。希望帮到你。本文还有配套的精品资源点击获取 
