一、从一次规则变更后的判定漂移说起
百度斗篷是本文的核心主题。上个月有个做招商加盟投放的客户，碰上一件挺典型的事。规则库就动了一条，跟请求头优先级有关，上线两天之后，后台开始出现异常——原本一直稳定放行的某类来源，判定结果零零散散地往拦截那边偏。比例倒不算高，可它一直在偏。麻烦的地方在哪儿呢？没人能说清楚这条改动到底波及了哪些流量。线上流量天天在变，昨天的请求样本，今天未必还能重现出来。事后他们复盘，发现问题不在监控，缺的是另一套东西：在改规则之前，能把旧请求重新跑一遍的机制。
百度斗篷流量回放干的就是这件事。它把线上真实访问请求的输入特征连同判定上下文一起存下来，规则变更前后各跑一次，同一批请求的判定结果有没有出现非预期变化，直接摆出来看。跟依赖线上指标事后发现异常相比，这套做法把验证动作挪到了发布之前，"改了什么、影响了谁"也不再是拍脑袋，而是有对照结果可看。
二、概念定义与组成结构
百度斗篷流量回放，指的是这么一套验证方法：对经由百度斗篷判定链路处理的真实访问请求，把它的判定输入采集下来——请求头、来源标识、设备与环境特征、访问路径、时间上下文这些——形成可复现的样本；规则版本发生变更后，在受控执行环境里按原始输入重新执行判定，新旧两次结果逐条比对，确认这次变更符合预期、没引入非预期漂移。它包含两个动作，缺一不可：历史请求重演，说的是输入原样复现；规则回归验证，说的是输出差异确认。
2.2 四个组成部分
- 样本采集层：从判定链路入口处抓请求输入和判定依赖的上下文。采集点尽量贴近判定入口，中间环节改写输入的情况要避开。
- 上下文快照层： 判定时依赖的外部状态得一并固化，规则版本号、特征库版本、时段信息都算。不然重演时输入一样、环境不一样，结果出了差异也没法归因。
- 重演执行层： 隔离环境里加载指定规则版本，按录制顺序或分组回放样本，每条样本的判定分支和关键中间量都输出出来。
- 差异比对层： 拿旧版本判定结果当基线，对新版本输出逐条对照，按分支翻转、置信度变化、命中规则条目变化这些维度分类统计。
三、重演机制：历史请求如何被复现
3.1 录制什么才算"可重演"
回放能不能成立，就看录下来的输入够不够完整。判定依赖的信号大概分三类：请求自身带的，请求头、User-Agent、来源页、访问路径与查询参数；会话与设备层面的，Cookie、指纹特征、会话标识；还有系统侧的，判定时刻、规则版本、特征库版本。前两类管判定输入，第三类管判定环境。只录请求不录环境，重演出来的差异你判断不了是规则改动引起的还是环境变了引起的，这种回放在实践里价值很有限。
3.2 重演的两种方式
按执行位置分，有离线重演和在线旁路重演两种。离线重演把样本导入独立的判定实例，加载目标规则版本批量执行，成本低、能反复跑，发布前的回归用它挺合适。在线旁路重演则是把录制流量复制一份送进新版本判定链路，跟生产链路并行执行，只比对不生效，更贴近真实时序，代价是要额外的链路资源和隔离设计。规则改动幅度大、涉及多个判定阶段时，旁路重演更容易暴露链路层面的问题；单条规则或者阈值微调，离线重演通常就够了。
比对结果不能光看"翻转了多少条"，这个数说明不了太多。合理的做法是分层看。判定分支翻转的样本，得区分是预期内的策略调整，还是非预期漂移。判定分支没变、但命中规则条目发生变化的样本，往往预示着后续版本的风险。还有一类是置信度或评分区间位移了、可没跨过阈值的，属于潜在漂移，得观察趋势。三类分开统计，"这次改动影响面有多大"才回答得出来。
四、与相邻概念的边界
4.1 与影子流量的区别
影子流量是把当前正在发生的真实流量复制一份给新版本，验证的是新规则面对当下流量的表现。流量回放验证的是新规则面对历史流量的表现。前者覆盖面随时间自然扩展，可样本不可复现，没法反复验证；后者样本固定、能重复执行，拿来做发布前的回归基线正好。两者是互补关系，谁也替代不了谁。
4.2 与灰度发布的区别
灰度发布是把新规则逐步放量到真实用户，用真实效果做决策，本质上是一次受控的线上实验。流量回放不接触真实用户，只比对判定输出。灰度回答的是"上线后效果如何"，回放回答的是"上线前会不会出问题"。规范的做法是：先回放做回归，确认没有异常，再进灰度。
抽样请求复现，通常是人工挑几条请求手工重跑，用来排查具体案例。流量回放是批量、系统化、带基线比对的工程流程。一个面向个案定位，一个面向版本验收，样本规模和统计口径完全不在一个层面上。
五、适用条件与边界
- 规则库存在多版本并行或者频繁迭代，改动的连带影响靠人工推演不出来。
- 判定链路包含多个阶段——特征提取、规则匹配、分支决策，阶段之间还有依赖。
- 对判定一致性有明确要求，需要留下可审计的变更验证记录。
5.2 明确的边界
流量回放覆盖不到录制窗口内没出现过的流量形态。新出现的来源特征、新的设备类型、新的访问路径，历史样本里都不会有，这类盲区只能靠灰度或者线上监控来补。回放也验证不了外部依赖的实时状态，比如特征库在重演时刻的在线查询结果跟录制时并不相同，这得靠快照固化去逼近，逼近到什么程度本身要如实记录。另外，录制样本涉及访问特征数据，存储和使用得按数据最小化原则设定保留周期与访问权限。
5.3 一个实战复盘
某工具类产品的投放团队，日均判定请求在一千多次点击对应的量级，服务器是一台中等规格的判定实例加一个独立的重演环境。他们最初的做法是改完规则直接上线，靠后台的分支占比曲线看有没有异常。有一次调整来源判定顺序之后，某类低频来源的放行结果出现持续偏移，等曲线看出来，大半天已经过去了。后来他们改成发布前必跑回放：每天固定录制一段判定输入，规则版本号一并固化；改规则时先在重演环境加载新版本跑一遍，比对报告里重点看分支翻转和命中条目变化两类。调整之后，规则变更引发的非预期漂移基本能在发布前被发现。他们踩过的坑是早期只录了请求没录规则版本，重演结果对不上，排查了两天才定位到是环境版本不一致，此后快照固化就成了硬性要求。
六、实施要点与常见误区
6.1 实施顺序
- 确定采集点与采集字段，保证判定输入完整可复现。
- 固化规则版本与特征库版本，建立版本与样本的对应关系。
- 搭建隔离重演环境，确保与生产环境在判定逻辑上一致。
- 建立基线： 以当前生产版本的判定结果为对照基准。
- 定义差异分类口径与可接受阈值，形成发布前的检查项。
6.2 常见误区
把回放当成万能验证，这是第一个误区。它只回答历史流量下的一致性，新流量表现如何它答不了。第二个误区是不做版本固化，重演时环境已经变了，差异没法归因。第三个误区，只看翻转总数不看分类，预期内的策略调整和非预期漂移混在一起，报告就失去了决策价值。第四个误区是样本长期不更新，录制窗口停留在几个月前，回放结论跟实际流量结构脱节，所以样本轮换周期得设定好。
回到概念本身：百度斗篷流量回放的价值不在技术复杂度，而在于把规则变更从"凭经验判断"变成"有基线可对照"。它跟影子流量、灰度发布、抽样复现各管一段，组合起来，才构成完整的规则变更验证链条。
