第2章

志摘要，里面有一串并不显眼的错误码，但被标了红色：REQ_CONS**TENCY_CHECK_FAILED。她把鼠标悬停在错误信息上，读到系统提示：请求一致性校验失败。
“校验失败？”林知夏喃喃，“这个一般不是支付**问题，更像是请求参数在链路中被改写或不一致。”
“所以我们怀疑是前端打包版本没更新干净。”小高在旁边插话。他说话时像在努力保持节奏，不想让情绪带乱逻辑，“但他们后端说接口兼容，应该没问题。”
林知夏没有立刻反驳。她看向更深层的内容：失败用户的请求里，某些字段值与服务端期待不匹配。最关键的是，有一部分用户的字段看上去“来自同一批前端”，但也有一部分像是被重放过，或者在缓存里被保留了旧版本的格式。
“重放？”她皱眉。
“不是我们定义的那种重放攻击。”旁边有人说，是运维的老陈。他声音低，带着烟嗓却没有烟味，“更像是**缓存策略没刷新。”
林知夏在脑内把可能性排了一遍。她知道“缓存没刷新”通常会导致旧字段仍被用在新接口上，从而引发一致性校验失败。但这又解释不了为什么“影响范围在扩大”。如果只是少数老缓存命中，故障不该不断扩张，除非某个新的触发因素让更多请求走进了缓存路径。
她把面板往下拉，注意到一个偏门的曲线：失败请求的来源渠道分布发生了变化。以前大头来自App内支付按钮，现在突然多了“第三方跳转后回流”的比例。也就是说，出问题的并不是单纯某版本前端，而是某种跳转链路的回流逻辑。
“第三方回流。”林知夏停顿了一秒，“你们看过回流参数的签名吗？”
老陈摇头：“还没到这一步，我们只看了失败码和**层日志。”
林知夏起身去拿白板笔。她在白板上画了一个简化链路：用户点击支付——前端发起请求——服务端校验——**转发——支付结果回传。她在“校验”处打了个圈，在“回传”处画了问号。
“如果只是参数不一致，那失败就发生在校验阶段，不影响回流。”她说，“但你们说失败率在扩大，还伴随回