格式化不会替你修复错误数据
JSON 格式化的作用是把可解析的内容按层级缩进，方便阅读和核对；它不会猜测缺失的逗号、补全引号，也不会判断某个字段值是否符合业务规则。发送接口响应或配置前，先确认输入本身来自正确环境，再处理副本。
例如同事让你提供一次支付接口的响应，你看到一整行 JSON 时很容易忽略 status、amount 或嵌套的 items。把副本格式化后，字段层级会显露出来，但测试 token、手机号和地址仍可能在里面，不能因为“只是格式化”就直接贴到群里。
先校验，再看报错位置
打开 JSON 格式化工具（json-formatter），把副本粘贴到输入框，选择校验或格式化。有效 JSON 会显示格式化结果与字段数量；无效内容会给出解析错误，并在能识别的位置提示行列。先回到原始文本核对该位置附近的引号、逗号、方括号和花括号。
- 对象用
{}包住，数组用[]包住，配对必须完整。 - 字段名和字符串值需要双引号，不能把 JavaScript 的单引号当成 JSON。
- 数字、
true、false和null不要误加引号，除非接口约定它们是字符串。 - 复制日志时注意前后是否混进了时间戳、HTTP 状态行或 Markdown 标记。
工具无法修复无效 JSON；遇到报错时，不要随手删除字符直到“变绿”。应该先知道这段数据本来应由哪个服务生成，并和接口文档或原始响应对照。
用字段和值做两轮核对
格式化完成后，第一轮看结构：顶层有哪些字段？每个数组是否还在？关键对象有没有被折叠成字符串？第二轮看值：金额的小数位、日期时区、ID 前导零和空数组是否符合预期。
比如原文含有 "orderId":"00128"，不能因为看起来像数字就改成 128；这会改变标识符。又如 items: [] 在 JSON 中本身就是无效写法，正确格式取决于它是字段名还是程序输出。格式化只证明语法可解析，不代表订单、库存或权限数据正确。
如果要向开发人员说明差异，可把旧版与新版分别复制到文本比较工具中，或在 Excel/数据库中按稳定 ID 检查大量记录。对于少量配置片段，可用 文本差异比较工具 按行查看增删；它比较的是文字，不会理解 JSON 的业务语义。
发送前移除秘密并保留可追溯副本
JSON 常包含 access token、cookie、邮箱、手机号、内部 URL 或客户资料。格式化后应再次搜索 token、authorization、password、email 等字段，并以占位符替换不该分享的值。不要只删掉值的一部分，因为前缀、长度和上下文也可能泄露信息。
发送时说明数据来自哪个环境、截取时间与是否已脱敏。若后续要生成类型草稿，可使用 JSON 转 TypeScript 工具 作为参考，但生成类型不能替代接口契约审查。保留未修改的受控副本，才能在对方提问时回到原始证据。
常见问题
格式化成功就说明接口数据正确吗？
不说明。它只表示内容能按 JSON 语法解析，字段含义、数值范围和业务状态仍要人工确认。
为什么格式化后字段顺序看起来变了？
应先比较原文和输出，确认工具没有改写值。字段显示顺序不是所有系统的业务排序依据，接口消费者也不应依赖它。
JSON 里可以用单引号吗？
标准 JSON 不可以。字符串与字段名应使用双引号；单引号常见于 JavaScript 写法，直接粘贴会导致校验失败。
可以把生产环境响应直接发到聊天群吗？
不建议。先建立最小可复现样本并删除秘密与个人数据，再按团队的安全流程发送。
文本差异工具能找出两份 JSON 的所有业务差异吗？
不能保证。它能显示文字层面的增删；对象顺序、数组匹配和字段语义仍需要按稳定键与业务规则检查。