JSON Swiss 标志

JSON Swiss

JSON 差异对比工具与 Diff 查看器

A：JSON A
B：JSON B
1
1

如何对比两个 JSON 并快速看清变化

1导入两份可比较的 JSON，而不是随便贴两个文本块2按场景配置忽略规则，而不是默认全开3用 diff 视图、统计和摘要一起判断变化是否重要4按用途导出摘要、报告或 JSON Patch

compare 的正确打开方式不是把两坨 JSON 往里一贴就结束，而是先确认输入质量，再根据业务场景决定要不要忽略顺序、空白或大小写，最后把结果输出成摘要、报告或 JSON Patch。这样它才真正适合版本变更、接口联调和数据迁移场景。

先理解版本差异，再决定怎么处理

compare 的价值不只是标红标绿，而是帮你快速回答“到底哪里变了”

很多时候你并不是要看每一个字符的变化，而是要判断：这个版本更新到底新增了字段、删掉了字段，还是只是重排了顺序。compare 适合做这种结构层面的快速判断。

JSON A（旧版）
1
{
2
"id": 1,
3
"name": "Maeve",
4
"status": "active",
5
"roles": ["admin", "editor"]
6
}
JSON B（新版）
1
{
2
"id": 1,
3
"name": "Maeve Winters",
4
"status": "active",
5
"roles": ["admin", "editor"],
6
"email": "[email protected]"
7
}

如果你只想确认字段有没有变，先看摘要；如果想知道具体在哪一层变，回到 diff 视图看高亮更高效。

3 个更贴近真实工作的 compare 示例

下面这 3 组示例基本覆盖了开发、测试和运维里最常见的 JSON diff 使用方式：接口版本变更、配置对比和迁移结果核对。

API 版本

对比 API 响应 v1 和 v2，快速确认新增字段

适合前后端联调、接口升级和回归测试时判断响应结构到底变了什么。

响应 v1
1
{
2
"user": {
3
"id": 42,
4
"name": "Maeve"
5
},
6
"status": "active"
7
}
响应 v2
1
{
2
"user": {
3
"id": 42,
4
"name": "Maeve"
5
},
6
"status": "active",
7
"profile": {
8
"email": "[email protected]"
9
}
10
}

这种场景特别适合先看新增字段，再决定要不要导出 JSON Patch 给测试脚本使用。

环境配置

比较预发和生产配置，排除顺序噪声后看真正差异

当对象键或数组顺序不是核心问题时，忽略顺序能显著减少无意义噪声。

预发
1
{
2
"features": ["coupon", "betaCheckout"],
3
"retry": 2,
4
"timeout": 5000
5
}
生产
1
{
2
"features": ["betaCheckout", "coupon"],
3
"retry": 3,
4
"timeout": 5000
5
}

开启忽略顺序后，你能更快看到真正重要的是 retry 发生了变化，而不是数组顺序。

迁移核对

确认数据迁移前后结构变化，并导出 Patch 记录

适合从旧结构迁到新结构时确认字段重命名、结构拆分和默认值补充是否符合预期。

迁移前
1
{
2
"fullName": "Maeve Winters",
3
"active": true
4
}
迁移后
1
{
2
"firstName": "Maeve",
3
"lastName": "Winters",
4
"status": "active"
5
}

如果迁移流程需要自动化回放，Markdown 报告和 JSON Patch 都很值得一起留档。

  1. 01

    教程步骤

    步骤 1 – 导入两份可比较的 JSON，而不是随便贴两个文本块

    先明确左边和右边各代表什么版本：旧版 / 新版、线上 / 预发、上一次响应 / 这一次响应。越早给自己建立语义，越不容易在后面看 diff 时混淆“是谁变了”。

    • 把基准 JSON 放在左侧，把新版本或目标版本 JSON 放在右侧，形成稳定的 A → B 心智模型。
    • 可以分别导入本地文件、URL 或剪贴板内容，适合比对导出数据、接口响应和配置文件。
    • 如果两份 JSON 还没校验过，建议先去 validator，避免语法错误干扰对比结果。
    • 处理真实业务数据时，尽量使用同一时间窗口或同一数据范围的 JSON，减少无关噪声。
    • 导入后先确认文件名或来源标签是否正确，避免把左右版本看反。
  2. 02

    教程步骤

    步骤 2 – 按场景配置忽略规则，而不是默认全开

    忽略空白、大小写和顺序都很有用，但它们服务的是不同业务语义。真正高效的做法是按场景开关，而不是一上来全部开启，否则你可能会把关键变化一起忽略掉。

    • 忽略空白适合在你只关心结构和内容、不关心缩进或换行时使用。
    • 忽略大小写适合字段值大小写不稳定、但语义相同的场景，例如标签、环境名或状态字串。
    • 忽略顺序更适合无序集合，不适合时间序列、步骤流或顺序本身带业务意义的数组。
    • 开启任一忽略规则后，编辑器会切到标准化预览，以保证你看到的差异和比较逻辑一致。
    • 如果你不确定要不要忽略顺序，先看一次原始 diff，再决定是否开启会更稳。
  3. 03

    教程步骤

    步骤 3 – 用 diff 视图、统计和摘要一起判断变化是否重要

    只看颜色块是不够的。真正有价值的信息通常来自三处合在一起：视图里的具体字段变化、状态栏里的数量统计，以及摘要里的高层概览。这三者结合，才能帮你判断变更是噪声还是实质变化。

    • 左右对照视图适合看字段级变化，尤其适合嵌套对象和较长 JSON。
    • 合并视图更适合移动端或只想快速扫一遍差异时使用。
    • 状态栏会告诉你总变更数，以及新增、删除、修改分别有多少。
    • 复制摘要适合快速贴给同事或写进工单，而不用手动总结变化。
    • 如果某个变化看起来异常大，先回到原始 JSON 检查是不是来源数据范围本身不一致。
  4. 04

    教程步骤

    步骤 4 – 按用途导出摘要、报告或 JSON Patch

    compare 的输出不只有“看一眼”。不同输出形式适合不同任务：摘要适合沟通，Markdown 报告适合记录，JSON Patch 适合自动化。你应该按下游使用场景来决定导什么。

    • 复制摘要，适合在聊天、工单、周报或联调记录里快速说明变化概况。
    • 导出 Markdown 报告，适合更正式的测试记录、变更评审和问题复盘。
    • 导出 JSON Patch，适合程序化应用变更或验证 A → B 的转换过程。
    • 如果变化来自配置文件，建议把报告和原始版本号一起保存，方便回滚和追踪。
    • 如果你下一步要逐字段人工核对，可把其中一份 JSON 送到 table editor 继续检查。

一个更稳的 compare 工作流

1

先校验两份 JSON，再导入 compare，避免无效 JSON 让 diff 结果失真。

2

先用原始规则看一次差异，再决定是否开启忽略空白、大小写或顺序。

3

结合高亮、摘要和统计一起看，先判断变化规模，再深入看字段层级。

4

需要沟通用复制摘要，需要记录用 Markdown 报告，需要自动化用 JSON Patch。

5

如果某一份 JSON 还需要人工逐字段核对，可继续送到 table editor 或 formatter 做后续处理。

compare 最适合回答的不是“这两个文本是不是一样”，而是“这两个 JSON 在结构和语义上到底哪里发生了变化”。

JSON 对比小贴士

如果你发现差异“多得离谱”，先检查两边是不是用了不同数据范围或不同时间窗口的 JSON。
顺序本身有业务意义时，不要轻易开启忽略顺序，否则可能掩盖真正的问题。
需要快速沟通时用摘要，正式留档时用报告，需要自动化时用 JSON Patch，各自职责不同。
如果 diff 看起来混乱，先去 formatter 统一结构，再回来对比往往更容易读。

相关 JSON 对比与 Diff 工具

将这些工具与 JSON 对比结合使用，可完成校验、格式化与代码生成等工作流。

校验 JSON

对比前先校验两份 JSON，确保语法正确。

格式化 JSON

先格式化以统一空白与结构，让差异更易阅读。

Schema 生成器

从 JSON 生成 JSON Schema，用于校验与约束后续变更。

JSON 转 TypeScript

从 JSON 生成 TypeScript 类型，便于在代码中进行类型安全的变更跟踪。

JSON 转表格

在交互式表格视图中编辑和可视化 JSON 数据。

常见问题

JSON 对比工具是如何工作的？

这页不是做文本逐字符比较，而是基于 JSON 结构去识别新增、删除和修改。它会在对象、数组和嵌套字段层面做结构化 diff，所以比普通文本对比更适合 API 响应、配置文件和数据快照。

我的 JSON 会上传到服务器吗？

不会。比较、标准化预览、摘要生成、Markdown 报告和 JSON Patch 导出都在浏览器本地完成，适合处理包含内部字段或敏感数据的 JSON。

忽略空白、忽略大小写、忽略顺序分别有什么作用？

忽略空白适合排除格式噪声；忽略大小写适合在键名或字符串值大小写不稳定时做宽松比较；忽略顺序适合数组元素顺序不重要、但内容集合是否变化更重要的场景。

忽略顺序时会不会把真正的变更也忽略掉？

有可能。如果数组顺序本身有业务意义，例如步骤流、排行榜或时间序列，就不应该开启忽略顺序。这个选项更适合标签列表、权限集合、配置项集合这类顺序不重要的 JSON。

为什么开启忽略选项后，编辑器会变成只读？

因为这时页面展示的是标准化后的预览，而不是你输入的原始 JSON。只读可以避免你误以为自己改的是原文，同时确保高亮和统计与实际比较规则保持一致。

JSON Patch（RFC 6902）有什么用？

JSON Patch 是一组标准化的 add / remove / replace 等操作，可以把 JSON A 程序化地转换成 JSON B。它很适合环境同步、自动化变更应用和接口测试场景。

对比前要不要先校验和格式化？

建议先校验。只有两份 JSON 都合法时，diff 才更可信。如果你想让结果更易读，也可以先用 formatter 统一缩进和结构，再进入 compare。

这页适合对比哪些场景？

常见场景包括：API 响应版本变更、环境配置差异、数据迁移前后结构核对、前后端联调时字段变更确认，以及线上问题回放时对比两次响应差异。

导出的 Markdown 报告适合怎么用？

它适合直接贴进工单、代码评审、变更说明或测试记录里。比单纯截图更清晰，也更容易让团队成员快速看到变更摘要和关键差异。

当两个 JSON 很大时，怎么提高对比效率？

优先先校验，再按业务模块拆分数据，必要时开启忽略顺序或忽略空白来减少噪声。如果只是想确认某个字段集合是否变了，也可以先提取局部 JSON 再进行对比。