简介基于Java的个性化旅游攻略定制系统设计与实现是一份本科毕业设计论文资料适合计算机相关专业学生完成旅游管理类信息系统选题也供初学Java开发者了解从需求分析、系统设计到编码测试的完整流程。整套资料仅1个docx文件压缩包约1.75MB包含中英文摘要、章节目录、绪论与后续正文系统围绕用户上传信息、旅游路线、景点项目、景点信息、标签分类等模块展开采用MySQL存储数据基于Java语言与Eclipse开发覆盖跨平台开发、数据库设计、信息管理等关键知识点。目前已有83人学习下载。借助这份文档读者能够获得系统总体架构、功能模块划分、数据库表设计以及旅游攻略生成思路的完整参考对毕业设计写作、系统实现和答辩准备都有实际帮助。1. 基于Java的个性化旅游攻略定制系统到底解决什么问题旅游App里的攻略大多是一个编辑团队写好的静态内容用户打开哪一篇都一样。而基于Java的个性化旅游攻略定制系统要解决的是另一件事同一个用户打开系统生成的攻略是根据他收藏、浏览、评分过的景点实时推算出来的换一个用户哪怕选同一个城市行程也不一样。这类系统看着不起眼做起来很容易把时间花在推荐算法上结果死在数据表设计和行为采集口径上。我把它当成一个 java 课程设计的经典选题来拆解适合做毕业设计、课程设计源码参考也适合中小型旅游平台做后台功能时直接照着落地。2. 数据模型先行把“个性化”落到MySQL表结构上推荐算法再花哨底层数据表设计错了也白搭。我在做这类系统时第一周不写一行 Java 代码先把表结构定清楚。个性化推荐系统的表设计和普通 CMS内容管理完全不同它需要同时支撑两类查询一类是面向用户行为的写入另一类是面向推荐计算的批量读取。前者要快后者要方便做聚合。2.1 七张核心表从用户、POI到行程明细一个最小可用的个性化旅游攻略系统我一般会设计七张表用户表user、景点表poi、景点标签表tag、景点标签关联表poi_tag、用户行为表user_behavior、攻略主表itinerary、攻略日程明细表itinerary_item。七张表缺一不可少了任何一张推荐或者路线生成都会出现逻辑断层。表名核心职责关键字段user用户账号与基础属性id, city, preference_jsonpoi景点静态信息city, name, lat, lng, open_time, close_time, scoretag标签字典id, namepoi_tag景点与标签多对多poi_id, tag_iduser_behavior浏览/收藏/评分行为记录user_id, poi_id, type, scoreitinerary攻略主表user_id, city, title, statusitinerary_item攻略每日行程明细itinerary_id, day_no, poi_id, start_timepreference_json这个字段值得多说一句。很多设计会把用户偏好拆成一张独立的偏好表但我倾向于在 user 表里保留一个 JSON 字段做冗余缓存理由很简单推荐接口在用户打开首页时就要返回结果如果每次都要去关联查询偏好明细接口延迟会明显上升。JSON 字段存的就是用户最终生成的标签权重向量由后台定时任务从行为表计算后写入查询时直接取用。2.2 建表DDL与关键索引选择建表时最容易被忽视的是经纬度精度和时间字段。经纬度用DECIMAL(10,6)精度大概到 0.1 米足够用于城市内路线规划如果偷懒用DOUBLE后续做距离排序时会出现大量不稳定的边界值。景点开放时间建议拆成open_time和close_time两个 TIME 字段而不是用一个字符串存“8:00-17:30”否则路线规划服务里做时间比较时每次都要做字符串解析。CREATE TABLE poi ( id BIGINT PRIMARY KEY AUTO_INCREMENT, city VARCHAR(32) NOT NULL, name VARCHAR(128) NOT NULL, address VARCHAR(256), lat DECIMAL(10, 6) NOT NULL, lng DECIMAL(10, 6) NOT NULL, avg_cost DECIMAL(8, 2) DEFAULT 0, open_time TIME DEFAULT 08:00:00, close_time TIME DEFAULT 17:30:00, duration_hours DECIMAL(3,1) DEFAULT 2.0, score DECIMAL(2,1) DEFAULT 4.5, status TINYINT DEFAULT 1 COMMENT 1上架 0下架, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, KEY idx_city_status (city, status), KEY idx_score (score) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这段 DDL 里有两个索引值得解释idx_city_status服务的是攻略定制页面“选择城市后拉取该城市可用景点”的场景这是整个系统最高频的查询idx_score服务的是冷启动时的基础热度榜新用户没有行为数据时直接按评分拉 TopN。duration_hours是路线规划的关键参数表示游玩一个景点大概要占用的时间这个值不要求特别精确从景点介绍页的描述里估出来即可。用户行为表是推荐系统的核心数据源它的设计直接决定推荐准确性。我要求行为表必须带唯一索引(user_id, poi_id, type)这样同一个用户对同一个景点的同一种行为只保留一条记录既能防止前端重复提交导致的重复计数也是后续数据一致性兜底的第一道防线。CREATE TABLE user_behavior ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL, poi_id BIGINT NOT NULL, type TINYINT NOT NULL COMMENT 1浏览 2收藏 3评分, score TINYINT DEFAULT NULL COMMENT 评分为1-5其他类型为空, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_user_poi_type (user_id, poi_id, type), KEY idx_user_time (user_id, created_at) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;idx_user_time这个索引是给画像计算任务用的定时任务按用户维度扫描行为时直接通过user_id加时间范围走索引不需要回表扫全量数据。score字段只有 type3 时才有值其他行为类型置空这个设计比拆成三张行为表更省事代价是代码里需要多做一次空值判断。2.3 行为数据的采集口径浏览、收藏、评分分属不同信号表结构定了之后紧接着要定的是行为采集口径。同一个景点用户看一眼和主动收藏对画像的贡献绝对不能一样。我在项目里默认的口径是浏览算 1 分收藏算 3 分评分按score - 3作为正负信号也就是给 4 分算 1给 2 分算 -15 分制的中性分是 3 分不做平移的话所有评分都会变成正向数据画像会被严重带偏。采集时机同样有讲究。浏览行为不要每次进入景点详情页都插一条记录而是在用户停留超过 15 秒之后才记录否则用户只是快速滑过列表页也会被算成一次浏览画像里会混入大量低质量信号。收藏行为和评分行为则是用户主动触发的前端调用接口时直接落库即可。这三个信号在后续用户画像模块里会被融入同一个 Java 实现。落地顺序上我建议先把表结构和采集接口做完用 Postman 模拟行为数据跑通一套简单推荐逻辑再回头调参数。很多团队一上来就追求算法复杂度行为数据却是空的最后推荐结果全靠默认热度榜撑着跟“个性化”三个字没有任何关系。3. 用户画像与推荐引擎协同过滤和标签相似度怎么在Java里落地推荐引擎是这套系统里最像“算法”的部分但真正的难点不在算法公式而在把用户行为转成可供计算的向量以及把多种召回结果融合成一个有序列表。我这个项目里同时用了基于标签的用户画像和基于用户的协同过滤前者解决冷启动时“用户喜欢什么类型”的问题后者解决“品味相似的人还去哪”的问题。3.1 用户偏好向量的构建标签权重与时间衰减景点打标是推荐的地基。每个景点挂 2 到 4 个标签比如“自然风光”“历史古迹”“亲子游”“登山徒步”。用户对某个标签的偏好强度由该用户所有行为中的标签累积权重决定。直接对所有行为做累加会有问题早期浏览的景点权重会一直保留用户兴趣已经转移了画像却还停留在三个月前。我一般会加入时间衰减行为发生时间越远对当前画像的贡献越小。/** * 用户偏好向量构建 * 标签权重 行为类型基础分 * 时间衰减系数 */ public class PreferenceVectorBuilder { // 行为类型权重收藏和评分比浏览更可信 private static final double WEIGHT_VIEW 1.0; private static final double WEIGHT_FAVORITE 3.0; private static final double WEIGHT_RATING 5.0; // 半衰期超过30天行为权重衰减一半 private static final double HALF_LIFE_DAYS 30.0; public MapString, Double build(Long userId, ListUserBehavior behaviors) { MapString, Double tagWeights new HashMap(); long now System.currentTimeMillis(); for (UserBehavior behavior : behaviors) { double baseScore switch (behavior.getType()) { case 1 - WEIGHT_VIEW; // 浏览 case 2 - WEIGHT_FAVORITE; // 收藏 case 3 - WEIGHT_RATING * (behavior.getScore() - 3.0); // 评分平移 default - 0.0; }; // 时间衰减Math.pow(0.5, 天数/半衰期) double ageDays (now - behavior.getCreatedAt().getTime()) / (1000.0 * 86400); double decay Math.pow(0.5, ageDays / HALF_LIFE_DAYS); for (Tag tag : behavior.getPoi().getTags()) { tagWeights.merge(tag.getName(), baseScore * decay, Double::sum); } } return tagWeights; } }这套逻辑的关键参数是三个行为权重和半衰期天数。WEIGHT_VIEW只给了 1.0因为用户滑到景点详情页的代价很小信号强度天然低收藏是主动行为给了 3.0评分权重给了 5.0 并且做了中性分平移这样差评才能产生负权重。半衰期 30 天是我在旅游场景里调出来的经验值旅游类用户兴趣转移速度比电商慢比资讯类快30 到 45 天是合理区间。计算出来的tagWeights是一个 Mapkey 是标签名value 是权重值。这个 Map 就是后续所有推荐逻辑的统一入口把它序列化存进 user 表的preference_json字段推荐接口直接从缓存里读取不需要每次实时计算。定时任务每天凌晨跑一次全量更新用户当天产生的行为要到第二天才会影响画像这在旅游攻略场景中完全可以接受。3.2 基于用户的协同过滤皮尔逊相关系数实现标签画像解决了“用户喜欢什么”但有一个明显盲区它只能推荐用户已经表现出偏好的类型无法发现用户自己都没意识到的兴趣。协同过滤正好补上这一块。基于用户的协同过滤核心是找到与当前用户行为最相似的“邻居用户”把这些邻居去过而当前用户没去过的景点推荐出来。/** * 皮尔逊相关系数计算用户相似度 * x、y 分别是两个用户的标签权重向量 */ public class PearsonSimilarity { public double compute(MapString, Double x, MapString, Double y) { MapString, Double common new HashMap(x); common.keySet().retainAll(y.keySet()); int n common.size(); if (n 2) { return 0.0; // 共同标签少于2个相似度无统计意义 } double sumX 0, sumY 0, sumXY 0, sumX2 0, sumY2 0; for (String key : common.keySet()) { double xv x.get(key); double yv y.get(key); sumX xv; sumY yv; sumXY xv * yv; sumX2 xv * xv; sumY2 yv * yv; } double denominator Math.sqrt((n * sumX2 - sumX * sumX) * (n * sumY2 - sumY * sumY)); if (denominator 0) { return 0.0; // 某一方所有维度取值相同避免除零 } return (n * sumXY - sumX * sumY) / denominator; } }皮尔逊相关系数的好处是它对向量中每个维度的绝对数值不敏感只关注两个用户标签分布的相对趋势。这句代码common.keySet().retainAll(y.keySet())做了向量对齐只保留两个用户都有行为的标签维度。n 2时直接返回 0.0是因为单个共同标签算出来的相似度噪声太大比如两个用户都只喜欢“自然风光”这一个标签相关系数会算出 1.0 的满分但实际上他们的共同兴趣证据太少。实际计算相似用户时不需要对全量用户两两计算。我一般用两步剪枝先通过preference_json粗筛出与当前用户至少有 3 个共同标签的用户控制在一个较小候选集里再在这个候选集里精确计算皮尔逊相关系数取 Top 20 作为邻居用户。这样能把计算量从 O(n²) 降到可控范围单机就能撑住十万级用户规模。3.3 相似景点召回与TopN排序综合评分公式有了邻居用户之后召回候选景点就很简单了找出这 Top 20 个邻居用户去过或收藏过、但当前用户没有行为记录的景点。但这里会遇到一个典型的同质化问题——所有用户都会被推给热门景点因为热门景点在邻居用户行为里出现的概率最高。为了削弱热门效应我在排序阶段会引入景点被行为覆盖的稀有度因子。public ListPoiScore rankCandidates(MapString, Double userPrefVector, ListPoi candidates, MapLong, Integer poiBehaviorCount) { ListPoiScore ranked new ArrayList(); for (Poi poi : candidates) { // 1. 画像匹配分景点标签与用户偏好向量的余弦相似度 double prefScore cosineScore(userPrefVector, poi.getTagWeights()); // 2. 协同过滤分邻居用户对该景点的平均行为强度 double cfScore poi.getNeighborScore(); // 3. 稀有度惩罚行为覆盖数越少越值得推 int behaviorCount poiBehaviorCount.getOrDefault(poi.getId(), 0); double rarityBoost Math.log(1.0 100.0 / (behaviorCount 10)); // 综合分 0.5 * 画像分 0.3 * 协同分 0.2 * 稀有度 double finalScore 0.5 * prefScore 0.3 * cfScore 0.2 * rarityBoost; ranked.add(new PoiScore(poi, finalScore)); } ranked.sort((a, b) - Double.compare(b.getScore(), a.getScore())); return ranked.subList(0, Math.min(30, ranked.size())); }这段代码里的三个分数权重 0.5、0.3、0.2 是我在不同数据集上反复试过的经验值。画像分占大头因为它直接反映用户明确表达的兴趣协同分是补充防止画像分把用户锁死在已有偏好里稀有度因子作用是给冷门优质景点一个出场机会100 / (behaviorCount 10)这个公式让行为数从 0 到 100 的变化过程中稀有度平滑下降不会出现某个冷门景点因为行为数恰好为 0 而分数暴涨。cosineScore的说明景点自身的标签权重向量在导入景点数据时就已经算好比如“故宫”的标签可能是“历史古迹: 5.0, 人文景观: 3.0, 亲子游: 2.0”存储结构与用户画像完全一致因此可以直接复用 PearsonSimilarity 里的公共维度对齐逻辑。两个向量的余弦值越高说明景点越匹配用户的口味。TopN 取 30 个是因为后续路线规划模块只需要从 30 个候选里挑太多了反而增加贪心搜索的时间。4. 把推荐变成攻略路线规划与Word文档导出推荐引擎输出的是一串景点列表用户要的不是这个而是一份能直接照着走的攻略。攻略定制系统还需要一个路线规划模块把 30 个候选景点按天分组、按时间排序、按交通衔接好最终还要能导出一份带章节结构、表格和备注的 Word 文档。这个模块在功能演示时最直观也是这个系统实现时翻车最多的地方。4.1 逐日路线生成的贪心策略路线规划本质是一个带约束的优化问题给定候选景点集合、每个景点的开放时间、建议游玩时长、景点间交通耗时求一个让用户体验最大化的游览顺序。精确求解需要动态规划状态空间在景点超过 10 个后就会爆炸。我在这类项目里采用贪心策略来做因为旅游场景的约束远多于收益贪心虽然拿不到全局最优但能保证每天行程在时间维度上可行。public ListItineraryItem planOneDay(ListPoi candidates, double startTime, double endTime) { ListItineraryItem plan new ArrayList(); ListPoi remaining new ArrayList(candidates); double currentTime startTime; Poi currentPoi null; while (!remaining.isEmpty()) { Poi best null; double bestValue Double.NEGATIVE_INFINITY; for (Poi poi : remaining) { double travel (currentPoi null) ? 0.0 : travelTime(currentPoi, poi); double arriveTime currentTime travel; // 必须保证至少能玩1小时并且不超过关闭时间 if (arriveTime 1.0 poi.getCloseTime() || arriveTime poi.getOpenTime()) { continue; } // 价值密度 用户偏好分 / (交通耗时 游玩时长) double value poi.getPrefScore() / (travel poi.getDurationHours() 1.0); if (value bestValue) { bestValue value; best poi; } } if (best null) { break; // 剩余景点都排不进去了 } double arrive currentTime travelTime(currentPoi, best); plan.add(new ItineraryItem(best, arrive, arrive best.getDurationHours())); currentTime arrive best.getDurationHours(); currentPoi best; remaining.remove(best); } return plan; }这段逻辑里最容易被忽略的坑是arriveTime 1.0 poi.getCloseTime()这个判断。很多初版实现只检查到达时间是否早于关门时间但游客进景点后要有基本的游玩时间刚开门就关门那还有什么体验。这里强制要求至少能玩 1 小时实际项目中可以根据景点类型调整博物馆类至少 1.5 小时网红拍照类 40 分钟就够。value prefScore / (travel duration 1.0)计算的是价值密度分母里1.0是平滑项防止交通耗时和游玩时长为 0 时出现除零溢出。prefScore来自推荐引擎返回的综合评分所以路线规划模块天然继承了个性化结果。同一批候选景点用户 A 的路线会优先排入高分景点用户 B 的路线则是根据他的偏好向量重新排序。每天的endTime一般设为 18:00 或 19:00晚餐后的夜游场景不在这个模块覆盖范围内需要单独做夜间景点推荐逻辑。4.2 用POI导出Word攻略内容组织方式攻略定制系统的交付物是文档而标题里的 .docx 后缀已经暗示了最终的落地形态。Java 生态里生成 Word 的主流方案是 Apache POIXWPFDocument可以完整操作 docx 格式的段落、表格、图片。经常有人问 java poi word 能不能生成图表POI 里的XWPFChart确实支持插入简单图表但兼容性一般而且用户在 WPS 里打开经常出现图表丢失的情况。我在攻略导出里一律用表格加文字评级替代图表反而更稳定。public void exportItinerary(Itinerary itinerary, OutputStream outputStream) throws Exception { try (XWPFDocument document new XWPFDocument()) { // 攻略标题 XWPFParagraph title document.createParagraph(); title.setAlignment(ParagraphAlignment.CENTER); XWPFRun titleRun title.createRun(); titleRun.setText(itinerary.getTitle()); titleRun.setBold(true); titleRun.setFontSize(18); // 按天数输出日程每一天配一个表格 for (ItineraryDay day : itinerary.getDays()) { XWPFParagraph dayHeader document.createParagraph(); dayHeader.createRun().setText(第 day.getDayNo() 天); XWPFTable table document.createTable(day.getItems().size() 1, 5); String[] headers {时间, 景点, 交通, 建议时长, 备注}; for (int i 0; i headers.length; i) { table.getRow(0).getCell(i).setText(headers[i]); } for (int i 0; i day.getItems().size(); i) { ItineraryItem item day.getItems().get(i); table.getRow(i 1).getCell(0).setText(formatTime(item.getStartTime()) - formatTime(item.getEndTime())); table.getRow(i 1).getCell(1).setText(item.getPoi().getName()); table.getRow(i 1).getCell(2).setText(item.getTransport()); table.getRow(i 1).getCell(3).setText(item.getDuration() 小时); table.getRow(i 1).getCell(4).setText(item.getNote()); } document.createParagraph(); // 表格之间加空行避免文档拥挤 } document.write(outputStream); } }POI 的表格默认不带边框导出后看起来会像一堆散落的文字。在实际项目中我会额外调用table.getCTTbl().getTblPr().setTblBorders(...)设置边框样式这段代码里没展开写但生产环境一定要加否则交付的 docx 文档观感很差。导出接口建议做成异步任务因为当行程超过 7 天、景点超过 50 个时POI 创建表格的时间能达到秒级同步返回会让前端一直转圈。4.3 攻略定制流程从景点选择到路线锁定路线规划的输入和输出都需要一个状态机来管理。用户从选城市开始到最终导出文档中间经历草稿、调整、锁定三个阶段。我建议在攻略主表 itinerary 里用 status 字段控制状态流转而不是让前端用布尔值离散地控制按钮显示。状态触发动作数据变化DRAFT用户选择城市和兴趣标签系统调用推荐引擎生成默认路线ADJUSTING用户拖拽调整景点或时间后端重新校验时间冲突返回提示LOCKED用户确认行程路线定稿生成可导出的正式版本EXPORTED用户点击导出写入导出日志标记已下载调整阶段是交互逻辑最复杂的地方。用户把某个景点从第三天拖到第一天后端的校验不能只改顺序还要重新检查第一天的交通路线是否连通、开放时间是否匹配。我的做法是每次调整只把受影响的当天行程重新执行一遍planOneDay其他天的计划不动既保证了局部一致性也避免整个攻略被打乱重排让用户困惑。5. 推荐系统中我踩过的坑冷启动、同质化与数据一致性这里集中梳理我在开发和迭代这类系统时反复踩过的坑每一条都对应一次线上问题或调试事故。把这些坑记下来比多写几个功能更有价值。5.1 冷启动新用户没有行为数据时推荐结果被默认城市污染现象新注册用户第一次打开首页推荐出来的景点和自己所在的城市完全不相关甚至出现南方城市用户被推北方滑雪场的情况。产品反馈“个性化推荐是假的”。原因用户画像构建模块对空行为数据直接返回空 Map推荐引擎里针对空向量的兜底逻辑退回到了全站热度榜单。而热度榜是全局统计的没有按城市维度过滤。用户画像为空时系统推的是“全世界最热的景点”而不是“他所在城市最热的景点”。解决在用户注册时采集城市信息存入 user 表冷启动推荐不再使用全站热度而是使用city status score组合查询本城市 TopN 景点。热度榜 SQL 改成WHERE city ? AND status 1 ORDER BY score DESC LIMIT 20并且对榜单结果做了去重同一个景区的不同分景点只保留评分最高的一个。另外给新用户默认注入一个基础偏好向量比如“自然风光: 1.0, 人文景观: 1.0”避免后续画像计算出现空向量导致各种空指针异常。5.2 同质化协同过滤把每个用户都推荐成同一份榜单现象线上推荐结果 A/B 对比显示个性化推荐和默认热度榜的相似度长期高于 60%。用户明明有不同的历史行为推荐出来的景点却大同小异。原因协同过滤的邻居集合被少数头部景点主导。热门景点在大量用户行为中都存在它们之间天然共享同一批邻居导致从邻居行为中召回的候选景点高度雷同。我最初用“邻居用户共同行为数”作为召回路劲热门景点行为数大被召回的频率就高。解决我在 3.3 节引入的稀有度因子就是这么来的Math.log(1.0 100.0 / (behaviorCount 10))让冷门景点的排序分获得额外加成。另一个有效手段是限制单个景点在最终推荐列表中的占比比如最终 Top 30 中同一个景区的景点不超过 3 个之前出现过用户被推荐了同一景区 8 个景点的情况路线规划里全排在一整天体验非常差。5.3 数据一致性并发收藏与行程更新导致画像写错现象用户快速连续收藏了两个景点后台日志显示两条行为都插入成功但用户画像更新后只统计到其中一条。排查后发现是定时画像任务和前端打点接口并发读写同一份preference_json后执行的写入覆盖了先执行的更新结果。原因画像更新是读-改-写三段式操作定时任务读取旧 JSON前端接口也读取旧 JSON两边各自计算完再写回后提交的覆盖了先提交的。这个问题的本质是丢了更新也就是常见的并发一致性问题在 Java 里如果只靠 synchronized 锁单机实例分布式部署时依然会失效。解决两个层面处理。第一层是行为表上的唯一索引uk_user_poi_type重复收藏直接插入失败从源头减少并发写同一份数据第二层是画像更新从“全量覆盖”改为“增量合并”定时任务不再读取旧 JSON 后整体覆盖写入而是直接基于user_behavior表做增量聚合然后把新结果通过INSERT ... ON DUPLICATE KEY UPDATE写入保证最终一致性。对于单机部署的课程设计场景用synchronized锁住画像更新方法也能解但要意识到这只在单实例下有效。5.4 中文与坐标数据处理POI导入时的编码和精度翻车现象通过 Excel 批量导入景点数据时景点名称带生僻字或者英文括号时显示乱码部分景点在地图上定位偏移超过 1 公里导致路线规划里两个景点的衔接交通时间算得离谱一天行程排完后严重超时。原因Excel 文件读取时没有显式指定字符集POI 读取 xlsx 格式时对中文兼容还好但读取旧版 xls 时容易丢失编码信息。坐标问题更隐蔽我拿到的一份景点数据里经纬度是度分秒格式代码里当成十进制小数直接用算出来的坐标整体偏移了一大截。解决导入模块里统一走 POI 的XSSFWorkbook读 xlsx读取单元格时强制DataFormatter转字符串。坐标写入库之前加一道校验逻辑纬度范围必须在 3 到 53 之间经度范围必须涵盖中国境内超出范围的直接打在导入日志里。交通时间计算不再依赖坐标反查地图 API而是用一个固定的速度模型估算城市内按每小时 25 公里算跨城市按每小时 80 公里算这样至少不会出现路线规划因为单条数据异常而直接卡死。5.5 路线时间冲突景点开放时间没参与约束行程表排出一堆“白天关门”的景点现象生成的三天攻略里某天上午 10 点安排了一个 12:30 才开门的景点。用户按攻略到了门口才发现没开放行程彻底被打乱。原因路线规划候选景点的open_time字段在数据库里全是默认值数据导入时没有从景点介绍页解析真实的开放时间。贪心算法只校验了arriveTime 1.0 closeTime没校验arriveTime openTime导致开始时间早于开门时间的景点也被排入。解决贪心代码里补上arriveTime poi.getOpenTime()的判断同时引入“等待惩罚”。如果到达时间比开门时间早 30 分钟以上这个景点的价值分直接乘以 0.5 打折避免为了一个高评分景点让游客在门口干等。数据侧把真实开放时间作为 poi 表必填字段导入时从景区官网或介绍页抓取并人工抽查不能放任为默认值。6. 上线前怎么验证推荐质量离线评测与行为回放推荐系统上线前不能只靠“我感觉推荐得挺准”来验收需要一套可量化的离线评测流程。我用的最有效的方法是行为回放把历史行为数据按时间切成训练集和验证集用训练集里的行为构建画像和推荐列表看看验证集里的真实行为有多少能被推荐列表命中。这个思路和做搜索排序评测类似只是指标不同。指标计算方式参考区间命中率验证集行为中出现在推荐 Top 30 的比例大于 25% 说明基本有效覆盖率推荐结果覆盖的景点数 / 全量景点数低于 10% 说明同质化严重新颖度推荐列表中非热门景点的占比常规区间 20%~40%离线评测的关键是严格按时间切分不能用同一时间段的数据既训练又验证否则推荐系统等于开卷考试指标虚高到没有参考价值。行为回放时还容易忽略一件事浏览行为和收藏行为的验证权重不能一样收藏被命中说明推荐质量高浏览被命中可能只是热门效应。我一般把收藏行为的命中率权重设为浏览的 3 倍这样最终指标主要反映推荐对强信号行为的有效性。评测之后还有一道线上对照的坎。很多团队直接上 A/B 测试测试两组用户的点击率差异但在流量不足的早期阶段A/B 测试的置信区间会宽到没有意义。我的习惯是把离线命中率达到 25% 作为放量门槛没有达到这个数字就不要往生产环境推。这个标准看起来保守但能避免把明显有问题的推荐算法放出去让用户承担试错成本。我在这套系统上吃过最大的亏就是第一版上线前没做行为回放只靠手工体验了几次就认为推荐准了。结果线上真实用户反馈里全是“推的都是我去过的景点”“推荐来推荐去就那几个”。后来补上离线评测流程才发现问题根源不在算法实现而是行为采集时把滑过详情页也算成了有效浏览。从那以后我养成了一个习惯每动一次画像权重参数就先把离线评测跑一遍再考虑要不要更新线上配置这个习惯帮我躲过了不少数据翻车事故。希望帮到你。本文还有配套的精品资源点击获取