发版前、排障时、回归核对时，如何在线对比 API 响应

接口返回变化后，先对比旧 payload 和新 payload，再判断它是预期调整、无害噪音，还是会阻断发版的问题。JSON Diff 能把注意力放在字段、值、数组和嵌套结构上，而不是空格。

从你已有的输入开始

当 staging 与 production 返回不一致，当 Postman collection 的字段突然变化，当发版候选版本改动了嵌套对象，或者 QA 要验证回归修复是否真的生效时，这类页面最有价值。

接口输出常会同时出现格式、嵌套和字段顺序变化。结构化审查比纯文本对比更容易看出真实行为差异。

把旧响应放左边，把新响应放右边，先规范化 payload，再看结构变化，最后再把结论带回 PR、缺陷单或发版说明里。这样团队讨论的是接口真实变化，而不是缩进和空格。

如果某一侧 JSON 已经损坏，先走 JSON Repair。如果输出已经不是 JSON，而是文档或导出文件，就应该切到 Text Diff 或 PDF Diff。

更多入口

当 payload 已经存在于 fixture、导出文件或 manifest 里时，走文件级页面更合适。

当 payload 和原始文本看起来都能比时，这页能帮你更快选对工作流。