简介：基于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_json |
| poi | 景点静态信息 | city, name, lat, lng, open_time, close_time, score |
| tag | 标签字典 | id, name |
| poi_tag | 景点与标签多对多 | poi_id, tag_id |
| user_behavior | 浏览/收藏/评分行为记录 | user_id, poi_id, type, score |
| itinerary | 攻略主表 | user_id, city, title, status |
| itinerary_item | 攻略每日行程明细 | itinerary_id, day_no, poi_id, start_time |
preference_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) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;这段 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) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;idx_user_time这个索引是给画像计算任务用的，定时任务按用户维度扫描行为时，直接通过user_id加时间范围走索引，不需要回表扫全量数据。score字段只有 type=3 时才有值，其他行为类型置空，这个设计比拆成三张行为表更省事，代价是代码里需要多做一次空值判断。
2.3 行为数据的采集口径：浏览、收藏、评分分属不同信号
表结构定了之后，紧接着要定的是行为采集口径。同一个景点，用户看一眼和主动收藏，对画像的贡献绝对不能一样。我在项目里默认的口径是：浏览算 1 分，收藏算 3 分，评分按score - 3作为正负信号，也就是给 4 分算 +1，给 2 分算 -1，5 分制的中性分是 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 Map<String, Double> build(Long userId, List<UserBehavior> behaviors) { Map<String, 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是一个 Map，key 是标签名，value 是权重值。这个 Map 就是后续所有推荐逻辑的统一入口，把它序列化存进 user 表的preference_json字段，推荐接口直接从缓存里读取，不需要每次实时计算。定时任务每天凌晨跑一次全量更新，用户当天产生的行为要到第二天才会影响画像，这在旅游攻略场景中完全可以接受。
3.2 基于用户的协同过滤：皮尔逊相关系数实现
标签画像解决了“用户喜欢什么”，但有一个明显盲区：它只能推荐用户已经表现出偏好的类型，无法发现用户自己都没意识到的兴趣。协同过滤正好补上这一块。基于用户的协同过滤核心是找到与当前用户行为最相似的“邻居用户”，把这些邻居去过而当前用户没去过的景点推荐出来。
/** * 皮尔逊相关系数计算用户相似度 * x、y 分别是两个用户的标签权重向量 */ public class PearsonSimilarity { public double compute(Map<String, Double> x, Map<String, Double> y) { Map<String, 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 List<PoiScore> rankCandidates(Map<String, Double> userPrefVector, List<Poi> candidates, Map<Long, Integer> poiBehaviorCount) { List<PoiScore> 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 List<ItineraryItem> planOneDay(List<Poi> candidates, double startTime, double endTime) { List<ItineraryItem> plan = new ArrayList<>(); List<Poi> 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 POI，XWPFDocument可以完整操作 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% 作为放量门槛，没有达到这个数字，就不要往生产环境推。这个标准看起来保守，但能避免把明显有问题的推荐算法放出去让用户承担试错成本。
我在这套系统上吃过最大的亏，就是第一版上线前没做行为回放，只靠手工体验了几次就认为推荐准了。结果线上真实用户反馈里全是“推的都是我去过的景点”“推荐来推荐去就那几个”。后来补上离线评测流程，才发现问题根源不在算法实现，而是行为采集时把滑过详情页也算成了有效浏览。从那以后，我养成了一个习惯：每动一次画像权重参数，就先把离线评测跑一遍，再考虑要不要更新线上配置，这个习惯帮我躲过了不少数据翻车事故。希望帮到你。
本文还有配套的精品资源，点击获取
