JSON 的字段顺序变了，为什么签名就对不上了？

1规范怎么说的

原文其实已经给了提示。

把这句话记住就够了：规范化不是为了好看，而是为了让「语义相同的两份数据」在字节层面也完全相同。签名方案要么约定规范化算法，要么直接对原始字节签名并要求原样传递。

2为什么签名对字节敏感

几种常见场景都栽在同一个点上。

令牌类签名

签发方是对编码后的原始载荷字节做签名，规范明确说编码前不做规范化。所以载荷里键序或空白变一个字节，验签立刻失败。

回调通知的验签

很多服务把请求体原文参与签名计算。中间只要有一层代理重新序列化过 JSON，字节就变了。

内容寻址与缓存键

用摘要做标识时，同一份数据的不同序列化形式会得到不同的标识，缓存命中率骤降。

幂等与去重

用摘要判重时，同样的内容因序列化差异被当成两次不同请求，去重逻辑失效。

一个实用做法：校验和计算之前，先按确定的规则重排键并固定紧凑格式，再做摘要。这样无论上游怎么序列化，计算结果都一致。

3重复键与精度这两处也常出事

它们和顺序问题同源，都来自「规范允许、行为不定」。

重复键是合法的

规范并不禁止同名成员出现两次，但明确说遇到重复名时软件行为不可预测：有的取最后一个，有的取第一个，有的收集全部，有的直接报错。

所以重复键必须当 bug 处理

不能依赖任何一种解析结果。生成数据时要保证键唯一；收到可疑数据时先做检查，而不是默默接受。

数字精度有安全区间

整数只在某个绝对值范围内才能被通用实现精确表示，超出后不同语言可能给出不同结果。大整数建议用字符串传递。

注释和尾逗号不是标准 JSON

带注释、尾逗号的写法属于扩展方言，严格解析器会直接拒绝。需要写说明就加一个约定的说明字段。

4对接时怎么少踩坑

几条可以直接落地的约定。

明确约定规范化方式

要么双方都按同一套规则重排与格式化，要么约定「签名对原始字节进行、传输必须原样转发」。

验签不要先解析再重新序列化

很多事故就是这一步引入的：解析之后重新输出，键序和空白都变了。要用原始字节参与运算。

统一编码

跨系统交换必须用同一种编码，且不要带字节序标记，否则前几个字节的差异就足以让摘要不同。

把幂等键和签名分开

用稳定的业务键做幂等判断，而不是用整份报文的摘要，能避免大量因格式差异产生的误判。