JSON 差异对比工具

文本对比工具（比如本站自己的文本差异检查器）是逐行比较两段文字——它并不知道什么是 JSON，所以重新格式化文档、调整键的顺序，或改变缩进，即使底层数据完全相同，也会显示出一整片被标为更改的行。这个工具会先把两侧都解析为真正的 JSON，再比较得到的结构——所以 {"a":1,"b":2} 和一个把 "b" 排在 "a" 前面的格式化版本，会被正确地报告为没有任何差异。只有真正的新增、删除和数值变化才会显示出来。

"更改"意味着该路径上的值仍然是同一个 JSON 类型，只是值不同了——比如一个数字从 5 变成 6，或者一个字符串从"草稿"变成"已发布"。"类型更改"则意味着类型本身发生了变化——原本是布尔值的字段现在变成了字符串，或者一个数字变成了 null。这个区分在实践中非常重要：类型变化更有可能破坏读取该字段的代码（一个期望布尔值的函数，如果突然收到字符串就会出错），所以这个工具会把它单独标记出来，而不是和普通的数值更新混在一起。

按顺序逐项比较：索引 0 对索引 0，索引 1 对索引 1，以此类推，较长数组末尾多出的元素会被报告为新增或删除。这种方式简单且可预测，但也意味着在数组中间插入一个新元素，会让它之后的所有元素看起来都被更改了，即使它们实际上完全相同——因为它们全都整体后移了一个位置。这是基于位置的数组比较普遍存在的局限（不只是这个工具），所以对于顺序可能变化的数组，通常值得检查一下被标记为"更改"的项到底是真的不同，还是只是被移位了。

会在该文本框下方显示你浏览器自带的 JSON 解析器给出的确切解析错误，而不是悄无声息地失败或显示过时的结果。常见原因包括对象或数组最后一项后面多了一个逗号（在 JavaScript 对象字面量中合法，但在 JSON 中不合法）、键名周围缺少引号，或者混入了注释——JSON 完全没有注释语法，这一点和 JavaScript 或 JSON5 不同。

可以，这也是最有用的用法之一：粘贴一个变更前捕获的响应和一个变更后捕获的响应，每一个被新增、删除，或者——关键是——类型发生变化的字段都会被标记出来。某个字段悄悄从数字变成字符串，或从布尔值变成 null，正是那种在两个庞大的响应体里肉眼很容易漏看、却会真正破坏功能的变化，但在这里会立刻显示为一条独立的"类型更改"记录。

完全不重要——两个拥有相同键和值的 JSON 对象，无论这些键的书写顺序如何，都会被视为相同，因为 JSON 本身并未赋予键顺序任何含义。这也意味着，一份压缩成单行的 JSON 文档和同样数据、排版整齐的多行版本，在这里会被正确地判定为零差异。

不会。两份文档完全在你的浏览器中使用纯 JavaScript 解析和比较——不会上传到任何服务器，因此可以放心粘贴真实的 API 响应、配置文件，或其他不希望离开你设备的数据。

对于典型的 API 响应和配置文件——从几行到几千行——它都能轻松处理，因为整个比较过程都在浏览器标签页中同步运行。对于真正巨大的文档（几十兆字节），遍历每一个键和数组索引的递归过程可能会明显变慢；如果出现这种情况，通常把两份文档都裁剪到你真正关心的部分再比较会有帮助。

它们回答的是不同的问题，更适合搭配使用而不是相互替代。版本控制的对比是基于文本的——它会显示文件中确切更改的行，包括重新格式化、重新缩进，或者某个代码检查工具重新排列了键的顺序，而这些在本工具看来都不算真正的差异。本工具回答的是一个更聚焦、往往也更有用的问题，通常出现在某个格式化工具或自动生成的文件改动之后：配置到底是真的变了，还是只是格式变了？在可疑的提交上同时运行这两种对比，是快速区分"不用担心，只是重新格式化了"和"这确实改变了行为"的好办法。

同样可以处理——如果最顶层本身的形态就不同（一边是对象，另一边是数组，或者其中一边是原始值），会将其报告为一条根级别的差异，而不是强行进行一个没有意义的比较。用来标记嵌套字段类型变化的同一套逻辑，也适用于根节点：这被视为两个 JSON 文档之间最根本的一种差异。

只是作为附带效果——每一侧都会被解析以便比较，所以无效的文档会显示解析错误，而不是悄悄地什么都不比较。但这个工具的本职工作是比较两份已经合法的 JSON 文档，而不是格式化或自动修复其中一份。如果你需要验证、重新格式化或压缩单个 JSON 文档，本站的 JSON 格式化与验证工具正是为此而设计的，也是在这里粘贴文档之前很自然的第一步。