JSON Formatter：API 调试工作流

JSON 调试不是把 payload 美化一下就结束。在 API 工作里，formatter 真正有用的地方，是把三个问题分开：这段文本是不是合法 JSON，服务端实际返回了什么结构，哪个字段或嵌套模式不符合接口契约。

格式化前先保留原始 payload

使用 JSON Formatter 前，先把原始请求或响应按日志、浏览器 Network、webhook 投递记录或工单里的样子保存下来。格式化副本比直接修改唯一证据更安全。

这在问题和空白、转义、复制引号、日志截断或编码层有关时尤其重要。格式化版本方便人阅读，但原始值才是 API 实际产生或接收的内容。

先校验语法，再解释数据

第一步先确认 payload 是否是合法 JSON。语法错误往往很小：trailing comma、单引号、从配置文件复制来的注释、未转义换行、未转义反斜杠，或者字符串边界断裂。

如果语法校验失败，不要马上分析业务逻辑。先定位并隔离第一个语法错误，再重新校验。payload 顶部少一个引号，可能会制造一串后续误导性报错。

比较格式化结构，而不是压缩字符串

两个 API 响应看起来差不多但行为不同的时候，先分别格式化，再用 Text Diff 比较。这样更容易发现缺失字段、类型变化、对象顺序差异和嵌套数组变化。

例如支付接口在一个环境把 `amount` 返回为数字，在另一个环境返回为字符串。压缩成一行的响应很容易隐藏这个差异；格式化 diff 可以直接暴露契约漂移。

谨慎处理包装或转义 JSON

很多系统会把 JSON 包在另一层里。响应字段可能保存一段 JSON 字符串，日志行可能包含转义 JSON，API 也可能先把 JSON 片段 Base64 编码再传输。不要把所有看不懂的值都粘贴进 formatter，并假设它一定是 JSON。

如果包装格式已经确认，再有意识地解开。Base64 包装的 JSON 应先用 Base64 Encoder 解码，再校验 JSON。转义 JSON 字符串应先当作字符串值检查，只有生产方明确把 JSON 存为文本时，才继续解析内层。

脱敏时不要改掉问题本身

生产 JSON 常包含 access token、邮箱、客户 ID、内部 URL、签名或个人数据。分享或粘贴到浏览器工具前必须脱敏，但脱敏不能破坏调试信号。

好的脱敏会保留字段名、嵌套、必要数组长度和值类型。把 token 替换成 `REDACTED_TOKEN`，不要替换成 `123`。把邮箱换成 `user@example.com`，不要换成空字符串。如果 bug 与缺失字段有关，就不要为了样例好看而补字段。

一套实用 API 调试流程

当 JSON API 请求失败时，可以按这个顺序处理：

• 保存原始请求和响应。
• 分别校验 payload 是否为合法 JSON。
• 对合法 JSON 副本做格式化。
• 用 diff 比较失败样例和正常样例。
• 只有确认存在 Base64 或 JWT 类包装时才解码。
• 脱敏 secret，同时保留类型和结构。
• 最后再对照 API schema 或预期契约。

这套流程把格式化放在正确位置：它让证据可读，但不能替代协议理解和 schema 校验。

FAQ

JSON Formatter 可以自动修复非法 JSON 吗？

它可以指出语法问题，也可以格式化合法 JSON，但不应静默帮你编造缺失字段、引号或括号。自动修复建议只能当线索，不能当事实。

为什么 JSON 合法，API 请求仍然失败？

JSON 语法合法只说明文本是 JSON。API 仍可能因为必填字段、枚举值、日期格式、认证信息或 schema 规则错误而拒绝 payload。

可以把生产 JSON 粘贴到在线 formatter 吗？

必须先脱敏。token、ID、邮箱、签名、内部 URL 和客户数据都应视为敏感信息，确认移除或替换后再使用浏览器工具。