仅有一个 webhook 的 HMAC 不匹配（名字里带重音符号的那个）

我敢打赌问题出在 JSON.parse 再 JSON.stringify 这一来一回上，而不是传给 update() 的编码。所以你改了编码才没有任何效果。

HMAC 是对合作方签名时的那段确切字节算的。你一旦解析再重新序列化，签的就是你自己的序列化结果，而不是他们的。对于紧凑格式的纯 ASCII payload，两者往往字节完全一致，所以 evt_2051 和 evt_1001 是碰巧通过的。evt_2044 含有非 ASCII 字符，序列化器就是在这里出现分歧的。如果合作方输出的是 Zo\u00eb Ram\u00edrez（转义形式，有些 Java/PHP/Python 编码器默认就这样），JSON.stringify 给你的却是字面的 Zoë Ramírez，摘要就变了。反过来也可能发生。键顺序、空白和数字格式也可能不同，但重音字符最符合你的现象。

解法是直接对 delivery.raw 做哈希，不要动它。

const expected = crypto
  .createHmac("sha256", secret)
  .update(delivery.raw)   // string or Buffer, exactly as received
  .digest("hex");

签名校验通过之后再调用 JSON.parse。如果你把投递记录存到了磁盘，也要确认写入的那一步没有重新编码或规范化文本。直接存原始 Buffer 最保险。

顺手再提一句，比较摘要请用 crypto.timingSafeEqual，不要用 ===。文档在 https://nodejs.org/api/crypto.html#cryptotimingsafeequala-b

希望有帮助，如果换成原始版本后 2044 修好了，也告诉大家一声。

const payload = JSON.stringify(body);

就是这一行有问题。合作方签的是他们自己的字节，不是你的 JSON.stringify 生成的东西。对我来说，这类文档里的“the JSON payload”一直都指原始 body。直接对 delivery.raw 原样做哈希，校验完再解析。

https://nodejs.org/api/crypto.html

对，就是这个。我会对 delivery.raw 做哈希，之后再解析。（我其他 hook 的 shell 脚本本来就是这么做的。）

关于运气我不同意，合作方文档里写了会转义非 ASCII 字符，所以 2044 本来就一定会失败。

我用 Stripe 风格的 webhook 时碰到过一模一样的问题，对原始 body 做哈希就解决了。文档见 https://nodejs.org/api/crypto.html#cryptotimingsafeequala-b

同意对原始 body 做哈希，不过“the JSON payload 总是指原始数据”这个说法我想稍微反驳一下。文档里经常这样含糊地写，这大概就是 tess.p 一开始踩坑的原因，对吧？

重放校验脚本还有一点要提醒。如果保存下来的投递记录是按 utf8 字符串读出来再写回去的，BOM 或 CRLF 的变化会以同样的方式破坏摘要。我会让 raw 从头到尾都保持 Buffer。另外，如果以后放在 Express 后面，你拿到 body 的时候 express.json() 已经把它解析过了。有两种绕开的办法。

// option A: keep the bytes next to the parsed body
app.use(express.json({
  verify: (req, _res, buf) => { req.rawBody = buf; },
}));

// option B: raw only on the webhook route, parse after verifying
app.post("/hooks/billing", express.raw({ type: "application/json" }), (req, res) => {
  // req.body is a Buffer here
});

我倾向 B，因为不容易不小心哈希错对象，但 A 对现有应用的改动更小。不确定评审时我会为哪个辩护。

我说的运气指的是通过的那几个，不是失败的那个。转义能解释 2044，但 2051 之所以能对上，只是因为他们的空白和键顺序碰巧与 JSON.stringify 一致，这一点并没有任何保证。