这篇东西我们拆开聊，基本上就是把日志回放验证这整套动作从头到尾过一遍。上个月有个做教育投放的团队，差点周五晚上就把新版跳转插件全量推上去。结果回放前一天的生产日志时发现，同一批请求在旧链路和新链路里居然返回了三个不同的页面版本，差异率比他们预设的放量阈值高出一截，最后硬是压到周一才上。跳转插件上线能不能成，说白了就看一件事：真实流量进来之前，你有没有拿历史请求把新决策链完整跑一遍，然后逐条比对它跟线上旧链路的输出差异。这篇就从空跑模式怎么开讲起，再说比对结果怎么读，最后聊什么条件下才允许放量。
为什么日志回放比构造测试用例更接近真实
人工构造的测试请求有个绕不开的毛病：你只会覆盖你想到的情况。生产日志里躺着的可不一样，那是真实访客的请求头顺序、残缺的Cookie、偶发缺失的UA字段、带了一串活动参数的落地页URL。这些组合往往比测试用例刁钻得多。日志回放的核心思路其实不复杂：把线上网关记录下来的原始请求（方法、路径、请求头、Cookie、来源IP段），按原时间顺序灌给新插件的决策入口，但不真正对外返回跳转，只记录它算出来的页面版本、命中规则ID、判定耗时。
这一步的产出物是一份"影子决策日志"，它和线上旧链路的日志构成对照组。
回放前要固定住的两组变量
- 输入侧：请求样本要覆盖至少一个完整的流量波峰波谷周期，别只截取白天的干净请求，夜间爬虫比例高时反而更容易暴露边界问题。
- 环境侧：回放环境的规则库版本、指纹库快照、Cookie策略配置必须与即将上线的版本完全一致，否则比对出来的差异分不清是插件逻辑问题还是配置漂移。
这里有个容易被忽略的点：回放环境的PHP-FPM进程数和线上如果差太多，判定耗时数据不可直接对比，但页面版本这类逻辑输出仍然可比。
空跑模式怎么配：让插件只决策、不跳转
空跑（dry-run）不是简单地把跳转语句注释掉。合理的做法是在插件入口加一个开关，走完整决策链但把最终动作替换为写日志。
通用Nginx层可以这样配合，把回放流量单独引导到空跑入口： BLOCK0
插件内部判断dry_run参数后，跳过header跳转与JS输出，改为把{请求指纹, 命中规则, 目标版本, 耗时}写入独立的回放日志文件。
注意别把空跑日志和正式访问日志混写在一个文件里，否则你后面做比对时要花大量时间做数据清洗。分开写，按天轮转，回放结束统一归档。
回放跑完，拿影子日志和旧链路日志做逐条比对，重点盯四个字段：
- 目标页面版本：这是最硬的指标，不一致就是逻辑差异，必须逐条查原因。
- 命中规则ID：版本一致但规则ID不同，说明条件命中顺序变了，短期内不影响结果，但会埋下后续调优的隐患。
- 判定耗时分布：新链路如果分位数明显抬高，先查是不是同步指纹查询拖慢了决策。
- 兜底触发比例：新链路兜底率突然升高，通常意味着某条过滤条件收得太紧。
比对差异率控制在一个可解释的范围内才叫验证通过。差异条目要能逐条归因，归不了因的差异就是风险。
从差异清单到放量：一次真实的回放复盘
那个教育团队的回放样本大约覆盖了一天半的请求量，比对下来差异主要集中在两类。第一类是携带历史活动参数的旧URL。新插件对参数过滤范围做了收紧，导致这批请求没命中关键词规则，落到了默认版本。这个属于预期内的行为变更，他们在配置里补了一条针对该参数前缀的兼容规则后重新回放，差异消失。
第二类更隐蔽：部分移动端请求的UA字段里混入了厂商定制标识，新链路的行为配置按更严格的匹配模式走，把这批请求判成了非目标设备。这类差异在构造用例里根本测不出来，因为测试用的UA都是标准串。他们最后放宽了该字段的匹配写法，而不是修改判定逻辑，改动面最小。
两轮回放后差异率降到可以接受的水平，他们又做了一件事：把回放流量按百分之一的比例打到线上真实入口，也就是灰度放量，观察真实返回的日志是否和空跑结论一致。这一步相当于用真实流量做最后一次交叉验证。
整个动作串下来，其实和跳转插件上线前自检的思路是一脉相承的，只是把验证手段从清单核对换成了数据比对。如果你对决策链本身的分层逻辑还不够熟，可以顺带补一下访客分层权重背后那篇，理解命中顺序是怎么排出来的，比对时看规则ID会更有感觉。
回放验证的收尾检查
回放不是跑完就完事，收尾阶段有几个动作不能省：
- 把本轮回放使用的规则库版本号、指纹库快照时间、样本时间范围记录在案，作为上线基线。
- 差异条目逐条标注处置结论：已修复、预期变更、暂不处理并说明理由。
- 空跑开关在上线后要保留一段时间，便于出问题时快速切回只决策不跳转的状态做二次比对。
- 上线后头几个小时，把线上日志和回放结论做一次抽样复核，确认真实环境没有引入回放环境里不存在的变量。
说白了，回放验证买的是"上线前见过一次"的确定性。真实流量里的请求组合千奇百怪，你没法穷举，但你可以用历史流量把已经发生过的情况先过一遍，把没见过的留给灰度阶段去兜。
小结
跳转插件的日志回放验证，本质是拿生产请求做一次不对外生效的全链路预演，再用逐字段比对把逻辑差异、规则顺序差异和性能差异分开定位。空跑模式要独立写日志、固定输入与环境变量，比对时盯紧版本、规则ID、耗时和兜底率，差异必须逐条归因，归不了因的就不放量。把回放和灰度接起来用，上线风险会小很多。
常见问题
日志回放会不会影响线上正在跑的跳转？
不会，前提是回放流量走独立入口，空跑模式只写日志不返回跳转指令。要注意的是回放环境如果和线上共用同一台机器的资源，大量回放可能挤占PHP-FPM进程，建议错峰跑或者单独部署一台回放机。
回放差异率多少才算可以上线？
这个要看情况，没有统一数字。关键是每条差异都能解释清楚，解释不了的差异哪怕只有几条也不能放量。如果差异都是预期内的配置变更导致的，归因清楚后重新回放确认收敛，就可以进入灰度。
回放样本要取多长时间的日志？
至少覆盖一个完整的流量周期，通常是一天到两天。如果你的投放有明显的工作日和周末差异，更好把两种日子都包进去。样本太短容易漏掉夜间爬虫和低峰期的边界请求。
空跑开关上线后要一直留着吗？
建议保留至少一个观察周期。它的价值在于出问题时你能快速切回只决策不跳转的状态做二次比对，而不用临时改代码。稳定运行一段时间确认没问题后再考虑移除，移除前记得同步更新部署文档。
延伸阅读
回放验证解决的是上线前怎么比对，而插件本身的安装与基础配置如果还没理顺，比对就无从谈起，下面这篇把安装环节和参数配置讲得比较细，可以配合着看。
