JSON对比

使用建议

适用场景、处理建议与下一步

粘贴或上传两份 JSON,直接查看新增、删除、修改和类型变化。它适合核对 JSON 文件、接口返回、配置变更、测试数据和上线前的结构化差异,而不是只比较字符和空格。

先把场景、流程和后续入口看清楚,再继续处理当前文件,会更顺手。

01

JSON 文本对比:先看结构变化,不被格式干扰

把旧 JSON 放左边、新 JSON 放右边。工具会按对象和字段路径列出新增、删除、修改与类型变化;键顺序、缩进和空白造成的噪音可以先处理后再看结果。

补充说明

这比逐行文本对比更适合接口联调、配置审查和回归测试:你能先确认 /data/user/name 这样的字段到底变了什么,再决定是否需要继续排查。

02

对比 API 响应:忽略动态字段,定位真正的回归

对 staging 和 production 的返回体时,可在设置中填入要忽略的路径,例如 $.timestamp、$.request_id 或 $.meta.traceId。这样每次都会变化的字段不会淹没真正的业务差异。

补充说明

先用“API 响应”示例了解输入格式,再粘贴自己的两份响应。JSON 不合法时,先到 JSON Repair 修复;日志或普通文稿则应使用 Text Diff。

03

JSON 文件对比:数组重排时按 ID 匹配

数组默认按位置比较,适合有固定顺序的列表。若接口返回的对象数组只是顺序改变,可切换为“按 ID 匹配”,并指定 id、sku 等唯一字段,避免把一次排序误判成大量修改。

补充说明

上传两份 .json 文件或直接粘贴内容后即可开始。这个流程适合 package.json、feature flags、测试 fixture、导出数据和环境配置的变更核对。

常见问题

常见问题

这些问题通常会在第一次使用时遇到,先看一遍会少走弯路。

回到工具继续

为什么不用普通文本对比,而要用 JSON Diff?

因为 JSON 场景更关心结构性变化,而不是格式噪音。JSON Diff 能更快帮助你对比 JSON 文件、接口响应、配置文件和数据导出的真实变更。

这个页面适合上线前检查和 QA 吗?

适合。它很适合做 API 回归检查、配置漂移确认、fixture 更新复核和迁移前后数据对比。

API 响应里的 timestamp、request_id 每次都不同,怎么对比?

在设置中的“忽略路径”输入这些字段路径,例如 $.timestamp 或 $.meta.request_id。工具会保留其他字段的结构化差异,方便只看真正的接口回归。

数组只是顺序变了,为什么会出现很多差异?

默认按数组位置比较。对于带唯一标识的对象数组,切换到“按 ID 匹配”并填写 id、sku 等字段名,重排就不会被当成一批新增和删除。

如果输入的 JSON 本身是坏的怎么办?

先打开 JSON Repair 修复,再回到 JSON Diff Online 正式比对。这样比直接拿损坏 JSON 做纯文本对比更高效。