JSON 比较

对 JSON 做文本 diff 通常不可读，原因是结构性的。两份文档可以语义完全相同却每一行都不同：键的顺序不一样、缩进不一样、一份被压缩而另一份已格式化。基于行的工具会把这一切都报成变更，而真正有差异的那一个字段则埋没在噪声里。

结构化比较会先解析两侧，再比较得到的值。键序不再要紧，因为对象按定义就是键到值的无序映射。空白不再要紧，因为它根本没有从解析中幸存。剩下的正是您所问问题的答案：哪些键被新增、哪些被移除、哪些保留了键而改变了值。

数组是结构化比较真正变难的地方，值得事先明白原因而不是被结果惊到。数组是有序的，所以位置承载含义，而在开头插入一个元素会让后面每个元素都移位一格。此时朴素的按位比较会把每个元素都报成已变更，这在技术上为真，却毫无用处。重新排列数组确实是一种变更，也应当被如实报告；实用的建议是带着「顺序」这个问题去读数组的 diff，而不是把它当成一份编辑清单。

类型变化尤其值得注意，因为正是它们会悄无声息地弄坏使用者。一个原本是数字 1、现在是字符串「1」的字段，在渲染出的 diff 里几乎一模一样，在下游所有严格语言中的行为却不同。用 null 替换一个缺失的键也是如此：在许多查看器里两者都显示为空，而对能区分它们的解析器来说含义并不相同。

常见用途决定了该怎么读结果。比较部署前后的 API 响应，能看出一次变更在传输层上究竟改动了什么，而这往往多于发布说明所声称的。比较两个环境的配置文件，能找出那唯一不同的开关，解释为何预发布正常而生产不正常。把测试夹具与真实输出相比，是把故障诊断从几分钟缩短到几秒钟的方式。

两份文档都在您的标签页中解析和比较，没有任何上传。这一点在本站比别处更要紧，因为比较两份生产负载意味着同时把两组真实的客户记录放在页面里。