别再传错版本：关于91网页版分流页面，你们问的那个点我终于整理清楚

别再传错版本：关于91网页版分流页面，你们问的那个点我终于整理清楚

前言 最近因为分流页面版本错发、缓存“顽固”或者分流规则弄混导致的线上问题不断被拉出来复盘。把我这段时间在实际项目里验证过、能直接用的套路整理成一篇，说清楚分流页面（尤其是像91网页版这种需要做设备/渠道/灰度路由的入口页）最容易踩的点和可落地的防错方法，方便你们上线前做一次“死磕式”检查。

分流页面的核心构成（先理清概念）

• 版本标识：页面自己和静态资源要能告诉人和机器自己是哪一个构建（build id / git hash / semver）。
• 路由/分流规则：按设备、渠道、地理或AB实验把用户分到不同页面或版本。
• 粘性策略：保证同一用户稳定在同一分流组（cookie、localStorage 或 server-side session）。
• 发布与回滚机制：灰度/金丝雀发布、快速回退手段。
• 监控与日志：记录每次路由决策、异常与关键指标。

要点与可执行做法（按上线流程顺序） 1) 版本命名和打包策略

• 每次构建产物至少包含三个信息：构建号、git commit hash、构建时间。把这些信息写到页面可读位置（如HTML注释/meta tag）和静态资源文件名里（带hash）。
• 静态资源使用内容哈希（content-hash），避免 CDN 缓存导致的“页面新、资源旧”情况。

2) 分流规则配置化且可热更

• 不要把分流逻辑硬编码到页面或服务里。把规则放配置中心或可编辑的后台（JSON/规则引擎）。
• 配置应支持灰度百分比、基于用户ID哈希的稳定分配、渠道优先级（例如：渠道参数 > cookie > idHash）。
• 配置改动需有版本记录和回滚按钮。

3) 明确优先级与覆盖规则

• 设计清晰的优先级表，例如：URL参数 > 测试白名单Cookie > 渠道标识 > 默认分配。把优先级写进接口文档，团队成员能快速查到。
• 如果支持通过URL强制切换版本（用于QA），确保该参数仅在测试环境或有权限的用户才生效，或通过签名校验防止滥用。

4) 粘性会话实现

• 建议用cookie记录分组ID并设置合理过期，对无cookie设备fallback到idHash分配；避免每次都重新分配导致用户体验不一致。
• 如果跨域或第三方域名涉及分流，确认cookie策略（SameSite、Domain）不会让分组丢失。

5) 灰度发布与回滚流程

• 上线先 Canary（小流量），观察关键指标（错误率、点击率、首屏时长）。确认无异常后再放量。
• 回滚应支持一键回退配置或直接把分流指向稳定版本，避免依赖慢 DNS 切换。
• 发布动作写入事件日志，便于追溯谁什么时候改了分流规则。

6) 监控和埋点要跟分流粒度一致

• 每次分流决策都应在日志里记录：时间、用户标识、分流规则ID、目标版本/页面。
• 关键指标（加载失败、首屏时长、转化率）按分流组维度统计，方便对比与回滚决策。

7) CDN 与缓存策略

• 页面和资源的缓存策略要区分：入口页面可以短缓存或不缓存，静态资源使用长缓存+hash。
• 上线新版本先确保 CDN 已刷新对应资源（使用版本化路径降低刷新需求），避免页面指向新构建却加载到旧资源。

8) CI/CD 与自动化验证

• 把分流变更纳入 CI：变更配置前自动化检查（语法、矛盾规则）、在沙箱环境预演分流结果。
• 上线流程中加入 smoke-tests（模拟不同渠道/设备的请求，确认分流目标正确）。

9) 本地/QA 调试手段

• 提供 QA 专用入口（签名参数或临时白名单）以便强制进入任意分流组，不依赖外部流量分配。
• 文档里写明如何通过 header/cookie/参数强制选择版本，并提供 curl 示例便于排查。

10) 发布沟通与责任归属

• 每次分流配置变更伴随 release note：改了什么、为什么改、如何回滚、检查点是什么、责任人和联系方式。
• 保持“发布+监控”紧耦合：发布后30分钟内负责人员在线观察关键日志与指标。

常见问题与快速排查步骤

• 用户看到旧/错版本

1. 刷新+隐身窗口试验（先排除浏览器缓存）。
2. 查看页面HTML注释或meta里的build id，确认是不是目标版本。
3. 用curl带上相同的cookie/header模拟请求，观察响应和重定向。
4. 检查CDN缓存是否命中旧资源，必要时手工刷新或检查hash路径。
5. 查看路由决策日志，查找该用户的分流记录（时间点、规则ID）。

• 分流用户不稳定（同一用户切换组）
• 检查cookie策略（是否被第三方阻止），检查分组粘性实现是否有短期过期或覆盖逻辑。
• 上线后指标突变
• 立即回退到上一个稳定配置，拉取灰度/Canary的指标对比，定位是哪条规则影响了流量。

预发布最小核查清单（复制到你的发布模板里）

• 构建版本信息可见（html/meta/hash）
• 静态资源已版本化并上传到 CDN，路径正确
• 分流配置已在配置中心上线，并有版本记录
• 分流优先级与参数说明已更新文档
• 灰度比例、回滚策略已设置并可执行
• 日志埋点能记录分流决策与版本号
• QA 能通过参数/白名单强制进入任意分流
• CDN 缓存策略确认（入口页短缓存或不缓存）
• 发布负责人与监控窗口人员已确认上线时间与报警阈值

收尾一句话 把分流当作“配置化的流量开关”来管理，而不是在页面里临时写死逻辑。做到版本可识别、规则可回滚、日志可追溯，线上出现“版本错发”的概率就会大幅下降。还有什么具体场景（比如渠道判断优先级、跨域粘性、CDN刷新策略）你们碰到过没？发个例子我帮你把排查流程写成可执行脚本。