第2章

端发起请求——服务端校验——**转发——支付结果回传。她在“校验”处打了个圈，在“回传”处画了问号。
“如果只是参数不一致，那失败就发生在校验阶段，不影响回流。”她说，“但你们说失败率在扩大，还伴随回流链路占比上升。那意味着错误可能在更靠近回传的节点。”
小高抬眼：“你的意思是结果回传的请求也在出问题？”
“不。”林知夏轻轻摇头，“我想的是：回流链路改变后，前端构建支付请求时使用了错误的上下文数据。上下文本应来自一次新的会话，但因为跳转回流没有正确刷新，会话上下文仍是旧的。于是校验失败，且由于更多回流发生，失败范围就会扩张。”
她说着把关键字段列出来：session_id、nonce、client_timestamp。她盯住client_timestamp，觉得不对。按理说时间戳应该由客户端生成并参与签名，除非客户端在某些情况下复用了旧的nonce。那会导致一致性校验失败，且很难从接口兼容层面解释。
“我需要看前端埋点。”她转头，“把这次事故中用户的关键字段抓出来。”
技术组的人面面相觑。看起来大家都在等她提供“产品侧的解释”，但真正要的是“数据证据”。林知夏从来不喜欢空谈。她迅速申请了查询权限，拉取了事故时间窗口内的样本数据。屏幕上出现一张表格，行数很少，却足够让人判断：回流用户的nonce重复率远高于常态。
“这就是了。”林知夏呼了一口气，像把胸口的紧绷往外放，“nonce重复导致校验失败。你们上线时有没有改动nonce生成逻辑，或者有没有改过埋点上报时机？nonce通常和会话启动时机挂钩。”
“没有动这块。”有人回答，“我们版本更新主要是支付页面的UI和一个促销券的逻辑。”
林知夏盯着那条“促销券逻辑”。UI改动和促销券逻辑都可能影响到参数构建与会话上下文使用方式。她把可能的因果线收拢到一次促销券请求的触发：如果券逻辑在支付前就触发，并且券触发依赖某段缓存或会话状态，那么可能在回流时产生时机错位，导致nonce被错误复用。
“促销券模块的代码谁负责？”她问。
“周祁。”技术负责人回答。他说到名字的时候没有太多情绪，却让整个屋子像被轻轻推了一下方向。林知夏记得周祁，他是团队里最擅长写“看起来没问题”的代码的人。他经常用一种温和的口吻提出建议，但他的建议里总有一层“我已经考虑过，你不用担心”的气味。那气味有时候像是自信，有时候像是在提前把锅移走。
林知夏没立刻追问。她只是把数据截图保存，然后对老陈说：“先把线上回滚策略再确认一遍。不要只回滚版本，顺便在**层加一个短暂的降级策略：对第三方回流来源的支付请求，强制要求nonce唯一校验通过，失败直接提示刷新支付页。”
老陈皱眉：“那用户体验会差一点。”
“但我们现在体验差是因为不稳定。”林知夏说，“如果继续扩大，会比体验差更糟糕。至少让用户知道自己要做什么。”
“行。”老陈点头，“我去开策略。”
她回到工位，把白板上的链路再画一遍，写下“回流=上下文错位”。她在最底下写了一个新的词：同谋。
这个词是她在凌晨两点半之后开始反复浮现的。她并不是玄学爱好者，但她对“异常”的嗅觉像动物一样敏锐。她不相信纯粹的事故。因为系统的错误码虽然像是随机，但时间点、触发条件、字段特征，却都像被精心摆放过。
她把“精心摆放”压回心里。她需要先得到证据。没有证据就不能指控任何人。可她同样清楚：真正危险的不是错误本身，而是有人可能利用错误制造混乱，或者掩盖真实的操作。
群里又有人喊她：“知夏，老板在问情况，他说你负责产品侧沟通。”
林知夏打开老板的聊天窗口，输入一段总结：支付失败率上升，定位到nonce重复导致一致性校验失