JSON 文本对比:先看结构变化,不被格式干扰
把旧 JSON 放左边、新 JSON 放右边。工具会按对象和字段路径列出新增、删除、修改与类型变化;键顺序、缩进和空白造成的噪音可以先处理后再看结果。
这比逐行文本对比更适合接口联调、配置审查和回归测试:你能先确认 /data/user/name 这样的字段到底变了什么,再决定是否需要继续排查。
粘贴或上传两份 JSON,直接查看新增、删除、修改和类型变化。它适合核对 JSON 文件、接口返回、配置变更、测试数据和上线前的结构化差异,而不是只比较字符和空格。
先把场景、流程和后续入口看清楚,再继续处理当前文件,会更顺手。
把旧 JSON 放左边、新 JSON 放右边。工具会按对象和字段路径列出新增、删除、修改与类型变化;键顺序、缩进和空白造成的噪音可以先处理后再看结果。
这比逐行文本对比更适合接口联调、配置审查和回归测试:你能先确认 /data/user/name 这样的字段到底变了什么,再决定是否需要继续排查。
对 staging 和 production 的返回体时,可在设置中填入要忽略的路径,例如 $.timestamp、$.request_id 或 $.meta.traceId。这样每次都会变化的字段不会淹没真正的业务差异。
先用“API 响应”示例了解输入格式,再粘贴自己的两份响应。JSON 不合法时,先到 JSON Repair 修复;日志或普通文稿则应使用 Text Diff。
数组默认按位置比较,适合有固定顺序的列表。若接口返回的对象数组只是顺序改变,可切换为“按 ID 匹配”,并指定 id、sku 等唯一字段,避免把一次排序误判成大量修改。
上传两份 .json 文件或直接粘贴内容后即可开始。这个流程适合 package.json、feature flags、测试 fixture、导出数据和环境配置的变更核对。
这些问题通常会在第一次使用时遇到,先看一遍会少走弯路。
因为 JSON 场景更关心结构性变化,而不是格式噪音。JSON Diff 能更快帮助你对比 JSON 文件、接口响应、配置文件和数据导出的真实变更。
适合。它很适合做 API 回归检查、配置漂移确认、fixture 更新复核和迁移前后数据对比。
在设置中的“忽略路径”输入这些字段路径,例如 $.timestamp 或 $.meta.request_id。工具会保留其他字段的结构化差异,方便只看真正的接口回归。
默认按数组位置比较。对于带唯一标识的对象数组,切换到“按 ID 匹配”并填写 id、sku 等字段名,重排就不会被当成一批新增和删除。
先打开 JSON Repair 修复,再回到 JSON Diff Online 正式比对。这样比直接拿损坏 JSON 做纯文本对比更高效。