一张图讲明白，17c官网站内推荐线路切换的逻辑，很多人一直搞反

一张图讲明白，17c官网站内推荐线路切换的逻辑，很多人一直搞反

引子 很多同学在接手站内推荐流量策略时，第一反应是“把个性化优先放最前”，或者把 AB 流量和白名单混在一块儿随意切换，结果出现用户体验不稳定、实验数据异常、日志难排查等一堆问题。下面用一句话和一张“心里流程图”把真正准确的优先级和切换逻辑讲清楚——适合直接拿去跟产品、研发和测试沟通的那种版本。

一张图的口头版（建议把这段变成图放到文档） [用户请求] ↓

1. 静态规则过滤（黑/白名单、设备限制、法务限制） ↓
2. 强制流量入口检查（运营手动强推、节日活动、紧急下线） ↓
3. AB/灰度实验判定（有实验且用户在流量组） → 若命中：走实验分配的路线（A 或 B 等） ↓
4. 个性化优先判定（有明确用户偏好或高置信度模型） → 若满足：走个性化推荐 ↓
5. 性能或可用性回退检查（线路健康、延迟、命中率） → 若异常：走备用线路（备用推荐服务/静态池） ↓
6. 全局默认推荐（通用热搜、人工精选）

为什么要按这个顺序？

• 静态规则（黑/白名单）属于硬约束，无法被业务实验或个性化覆盖，比如法务或合规需要立即生效，必须先过滤。
• 运营手动强推或紧急开关要即时生效，优先于长期的实验分流。
• 实验流量需要保证统计口径准确，因此当用户被分配进实验组时，应严格按实验配置走，避免后续步骤改变分流导致干扰。
• 个性化是对单用户长期数据的最优适配，但它不应破坏实验的随机性或运营的手动策略。
• 系统稳定性优先级最低但不可忽视：当线上推荐服务异常或超时，必须能无缝回退到备用方案，避免页面空白或超长等待。

常见误区（以及后果）

1. 把个性化放在实验之前 后果：实验组的用户会被个性化“打散”，导致实验效果被污染，无法得出可信结论。
2. 忽视静态规则优先级 后果：法务或黑名单用户仍能看到不该看的内容，风险暴露。
3. 没有备用线路或回退策略 后果：推荐服务波动时用户看到空白或加载失败，直接影响转化和留存。
4. 将运营强推与实验混用 后果：运营临时推送污染长期实验数据，产品判断失真。
5. 日志埋点不完整 后果：问题出现时无法定位是哪个环节出错（是路由判定、实验分组、还是推荐服务本身）。

一段伪代码，帮你把逻辑落地 function chooseRoute(user, page) { if (isBlocked(user) || !isAllowedDevice(user.device)) return 'deny'; if (isForcePushActive(page)) return 'forcepush'; if (isInExperiment(user, page)) return getExperimentRoute(user, page); if (hasHighConfidenceProfile(user)) return 'personalized'; if (!isPrimaryRouteHealthy()) return 'backuproute'; return 'default_generic'; }

实施细节（工程与运营角度的落地建议）

• 流量判定顺序编码为单一路由层（Gateway/Router）：避免在多个服务中重复判断，减少不一致。
• 实验系统集中管理：实验分配与开关由统一服务下发，所有调用方读取同一分流结果。
• 日志与埋点要到每个决定点：记录用户ID、命中规则、实验ID、候选路线、最终选中路线、响应时间、结果集大小等。
• 回退策略要自动化：当主推荐服务延迟或错误率超过阈值时，自动切换到备用服务并告警。
• 灰度与放量要分阶段：先 1% -> 5% -> 20% -> 全量，观察关键指标（CTR、转化、PV、响应时间、错误率）。
• 将运营“一键推送”做成带标识的强制流量，便于后续剔除或者统计影响。

监控与验证清单（上线前后都要看）

• 实验组/对照组的样本均匀性和规模
• 关键指标的实时对比（CTR、转化、平均停留）
• 路由判定日志覆盖率（每次请求都应有判定链路）
• 故障触发回退是否正常工作（模拟主服务宕机）
• 人群分布（日活、地域、设备）是否和预期一致
• 运营强推的生效与撤销是否可追溯

示例场景（帮助理解） 场景 A：法务要求下线某内容。正确做法：黑名单规则在路由最前，立刻屏蔽；不必等待模型重新训练或实验结束。 场景 B：正在做推荐算法 A/B 测试。正确做法：实验分流优先于个性化，确保实验组和对照组的用户在后端看到的候选池一致。 场景 C：推荐服务延迟飙升。正确做法：路由层检测到异常后自动回退到缓存或静态池，用户体验降级但不中断访问。

一张图要怎么画（给设计/PM）

• 横向流程图，按顺序从左到右画出六个决策节点（静态规则、强推、实验、个性化、回退、默认）。每个节点下方用小字标出“判定依据”和“埋点字段”。
• 在实验节点增加“实验ID/分组”的注记，并用虚线连接到“统计/监控”模块。
• 在回退节点画出心跳/探针机制和备用服务的箭头。
• 用红色标注“运营强推”和“黑名单”这两类能绕过常规逻辑的强制路径。

结语（一句话总结） 把“硬约束、运营强推、实验分流、个性化、回退、默认”当成标准优先级，从上到下严格判定，实验与个性化不互相侵占，才能既保证业务快速试错，又不牺牲用户体验和数据可信度。

需要我把上面的流程图做成 PNG 或 SVG，或者把伪代码改成你们语言的具体实现（Java/Go/Python），发给我你们现有的判定点日志样例，我可以直接帮你整理成可执行的路由规则清单。