AB页跳转流量回放：定义与概念边界
AB页跳转是本文的核心主题。线上经常碰到这么一种情况：规则上线之后，监控面板上的放行率曲线几个小时内慢慢偏了，但你一条条查规则，又找不出哪条写错了。人工去翻日志样本，能看到某些会话的判定结果跟规则文档对不上，可拿到测试环境里怎么试都复现不出来。这事儿跟规则本身关系不大，主要问题出在线上请求携带的上下文组合上——设备指纹、时间戳、来源参数、Cookie状态，这些东西在人工构造的测试用例里全丢了。
所谓AB页跳转流量回放，就是把生产环境里真实产生的访问会话完整录下来，放到一个隔离的验证环境里，按照原来的顺序和时序特征重新把请求发一遍，然后看跳转策略在新规则下跑出来的结果跟预期是否一致。它要回答的问题并非"规则写得对不对"，而是"规则放到真实流量结构里跑出来对不对"。
先把边界划清楚。流量回放跟压测是两码事，压测盯的是系统在并发压力下扛不扛得住，回放盯的是策略判定结果的逻辑一致性。它也不是简单的日志重发——你要是只把请求行和请求头复制出来再打一遍，会话之间的关联关系、时间间隔特征、客户端状态的演进全都丢了，验证结果跟线上实际表现之间会出现系统性偏差。
核心组成：录制、重建与验证三层结构
录制层干的事情，是在跳转决策节点把完整的请求上下文抓下来。要落盘的信息至少得有这些：请求头全集（User-Agent、Referer、Accept-Language这些都在内）、Cookie键值对、客户端IP及归属信息、请求到达时间戳（精确到毫秒）、还有跳转规则命中的决策路径标识。粒度得到单次请求级别，不能只做聚合统计。
这里面有个关键设计约束是采样策略。全量录制的话，高并发场景下存储成本根本控制不住；可采样率压太低，低频异常路径又覆盖不到。我见过比较稳妥的做法是按决策分支分层采样——命中率低于某个阈值的规则分支，把采样权重提上去。
重建层要做的是把录制数据还原成可执行的请求序列。这层的技术难点在于时序关系怎么保持住。同一个会话里的多个请求之间是有时间间隔的，重建的时候要是忽略这个间隔直接连着发，就会触发基于频率的异常检测逻辑，验证环境里跑出来的判定结果跟线上就不一样了。
还有客户端状态的演进也得处理好。Cookie在会话过程中可能被服务端更新过，重建时必须按原始顺序一步步推进状态，不能图省事把最终状态一次性注入进去。对于依赖设备指纹的跳转策略，重建环境得具备跟录制环境相近的指纹生成能力，不然指纹特征一有差异，判定结果直接就变了。
验证比对层
验证层负责把回放结果跟原始决策记录逐条比对。比对的维度有几个：跳转目标URL是否一致、决策耗时是否落在合理区间、规则命中路径是否相同。碰上不一致的条目，得标记差异类型——到底是规则变更导致的预期差异，还是环境差异造成的非预期偏移。
适用条件与边界
流量回放不是所有场景都值得往里投人力的。有这么几种情况适合引入：跳转规则集规模比较大、规则之间有优先级交叉、而且规则变更还挺频繁——这时候靠人工构造测试用例，覆盖成本会蹭蹭往上涨。另外就是线上出现了难以复现的判定异常，回放是少数能稳定重现问题的手段之一。
反过来说，下面这几种情况回放的收益就很有限了：规则集特别小、变更也低频，人工检查就能覆盖；跳转策略高度依赖实时外部信号，比如动态IP信誉库的实时查询结果，录制那会儿的外部状态在验证环境里根本还原不了；再就是流量结构本身正处于剧烈变化期，历史会话对未来的代表性不够。
有个实战案例能把边界说清楚。某工具类产品的投放团队，日均跳转请求在几千到一万出头，服务器是两台4核8G的云主机。他们上线了一批新的地域分流规则之后，发现某个地区的放行率从原来的水平掉了一半。规则文档逐条核对没问题，测试环境用构造请求也跑不出异常。后来把前一天的会话日志做了回放，才定位到问题：该地区用户的请求头里Accept-Language字段有大量非标准写法，新规则里的匹配模式没有覆盖这些变体。这个案例里，回放的价值就在于用真实流量结构暴露了规则覆盖盲区。调整方式是把匹配模式从精确匹配改为前缀匹配，并增加了一条兜底规则。回放验证通过后上线，该地区放行率恢复到原有水平。
与相邻概念的对比
流量回放与影子流量
影子流量是把生产环境的实时请求复制一份发到新版本服务上，用真实流量实时验证新策略。流量回放则是拿历史数据在隔离环境里验证。两者的核心区别在于时间维度和环境隔离程度：影子流量验证的是"此刻的流量在新规则下表现如何"，回放验证的是"过去的流量在新规则下表现如何"。影子流量的优势是无需重建上下文，劣势是验证结果跟线上变更同步发生，一旦发现问题，影响已经产生了。回放的优势是可以在变更前完成验证，劣势是历史流量的代表性受时间窗口限制。
流量回放与A/B测试
A/B测试是把真实流量按比例分配到不同策略版本，通过转化指标对比来判断优劣。流量回放不涉及流量分配，也不关心转化指标，它只验证策略判定结果的逻辑一致性。A/B测试回答的是"哪个策略更好"，回放回答的是"新策略是不是按预期在跑"。
实施中的关键约束
回放环境的网络拓扑应尽量与生产环境保持一致。如果生产环境的跳转决策依赖斗篷系统和CDN节点调度冲突时，链路分段定位该从哪一层开始查？">CDN边缘节点的本地缓存，回放环境缺少这一层会导致决策路径变化。对于依赖外部API的判定逻辑，回放时需要确认外部服务的响应是否可复现，必要时对这类调用做录制和回放代理。
拿到回放结果之后怎么解读，这里面有个讲究：得分清两类差异——由规则变更引起的预期差异，和由环境不一致引起的非预期差异。建议在回放前先做一次基线回放，用旧规则回放同一批会话，确认回放环境本身的偏差在可接受范围内，再切换到新规则做对比回放。
存储与计算成本需要提前估算。一次覆盖主要决策分支的回放，数据量通常在GB级别，重建和比对的耗时取决于会话数量和策略复杂度。对于日均请求量在数千级别的项目，单次回放可以在小时级完成；请求量到十万级别时，需要考虑分布式回放和结果聚合。
常见问题
回放通过是否意味着上线后不会出问题？
不是。回放验证的是策略逻辑在历史流量结构下的一致性，它无法覆盖上线后新增的流量类型和外部环境变化。回放通过是上线的必要条件，不是充分条件。
回放数据需要保留多久？
取决于规则变更的频率和问题回溯的需要。一般建议保留最近一到两个完整规则版本周期内的会话数据，覆盖至少一次完整的策略迭代。超出保留期的数据可以做聚合归档，释放存储空间。
