Node.js 支付回调验签偶发失败：我用原始报文、字段规范和证书缓存稳住校验

凌晨值班时，支付回调里偶尔蹦出验签失败。第一反应是时钟漂移或证书过期，但失败并不集中，且同一笔单重试有时又能过。因为失败只占很小比例，监控里像毛刺，容易被误当成网络抖动。后来发现真正的问题在请求进入业务代码前：日志中间件为了脱敏，把金额字段转成字符串；body 解析器又把空对象删掉。签名是对原始报文算的，业务层拿到的却是改写后的参数，自然偶发对不上。

先留住原始报文，再谈排查

我的做法是把原始请求体放在最前面处理：在 raw body 阶段保存 Buffer，同时写入 req.rawBody。后续无论做 JSON 解析、字段补全还是脱敏，验签都只认原始内容。回调记录会落到 MongoDB，方便回放；Redis 里再用通知 ID 做短期去重，避免重复处理把问题放大。如果用的是 Nuxt server API，也要注意不要在 nitro 插件里提前消费 body。

字段规范化：别让对象键序和空值捣乱

• 只取支付文档约定的白名单字段参与验签，不临时扩展。
• 金额统一用分，避免 0.1 和 0.10 混用。
• undefined、null、空字符串要区分，缺字段不能静默补 0。
• 对象或数组先按平台规则序列化，不要依赖 JS 对象键序。

const raw = req.rawBody || '';
const params = JSON.parse(raw);
const fields = ['out_trade_no', 'transaction_id', 'trade_state', 'amount'];
const data = fields.map((k) => `${k}=${params[k] ?? ''}`).join('&');
const ok = verifySign(data, params.sign, platformCert);

平台证书缓存要按序列号更新

证书也不能每次回调都去拉。平台证书有有效期，也可能轮换；频繁请求容易遇到限流，或者拿到刚切换的证书。我们把证书按 serial_no 存进 Redis，内存里再缓存一份；验签失败时先看证书序列号是否匹配，不匹配再刷新。这样既减少外部依赖，也避免把偶发网络抖动误判成签名错误。同时给证书设置合理 TTL，不要无限期缓存。

“支付回调的稳定，不是靠重试碰运气，而是把现场留下来：原始报文、字段规则、证书状态都要可追溯。”

上线这套流程后，验签失败从随机告警变成可定位问题：是报文被改、字段缺失，还是证书过期，一眼能分清。订单状态稳定后，小程序支付、广告结算和流量归因也少了很多脏数据。对做 Nuxt 或 Node 后端的朋友来说，这类基础链路越早收敛，后面越省心。排查支付问题，最怕只盯业务表；链路输入不变，输出才有可比性。