如何格式化 JSON 以便更快排错

API 返回一整行 minified JSON 时，真正的 bug 往往藏在肉眼难辨的逗号与引号之间。Pretty-print 不是「好看而已」——它把传输格式变成可在几秒内扫读的结构，是后端与前端联调的基本功。

从浏览器 Network、终端或日志里复制原始响应，粘贴到 Power Tools 的「JSON Formatter（JSON 格式化）」中。缩进可选 2 格（紧凑）或 4 格（便于 Code Review 贴图）。格式化同时做语法校验：缺引号、尾逗号等问题会直接标位置，不必逐行猜。

常见错误类型：一处引号缺失会引发连锁报错，先修第一条再重新格式化；数字被存成字符串（"200" 与 200）语法合法但比较会失败；PATCH 场景要分清字段是 null 还是根本不存在——缩进后一目了然。

结构清晰后，别从头到尾硬读。先找 envelope：data、result、items 等包装层；确认期望的是数组还是对象；有分页时先看 page、total、cursor 再进明细。

401/403 常与 JWT 有关。把 Bearer 后的 token（或解码器要求的裸 JWT）贴进「JWT Decoder（JWT 解码）」，优先看 exp：跨点过期会像「随机」失败；再核对 iss、aud 与自定义 claims（角色、租户 ID），排查类型或服务间不一致。

勿将生产 token 贴到公开 Pastebin 或截图外传；本地浏览器解码虽不上传第三方，公用机仍须清空输入。

字符串字段里可能套 escaped JSON 或 base64：外层格式化后，把内层再贴进 Formatter 二次解析。不少接口把错误 JSON stringify 进 message，不拆层看不到真实校验文案。

Webhook 等日志常混有头信息与 JSON，可先用「Regex Tester（正则测试）」提取 `{...}` 块，再在 Formatter 里美化，避免手工删时间戳前缀。对同样格式的日志固定一条 regex，批量处理更高效。

回归时需要与线上字节一致，可用 Formatter 的 minify 压回单行，便于 curl/Postman 复现。工单里可同时附缩进版（人读）与 minify 版（复现）。

建议个人 checklist：① 格式化并修语法；② 对照 OpenAPI/TS 类型；③ 涉及鉴权则解码 JWT；④ 日志杂糅则用 regex 提取；⑤ 删无关字段直到只剩最小失败样例。

团队可约定缩进与 key 展示习惯，减少 PR diff 噪音；Review 时要求贴文本 JSON 而非截图，便于搜索。

大数组别只盯 index 0：格式化后用业务 ID/email 搜索；超大粘贴可拆段或让 API 提供分页。

日志里可能出现密码、refresh token 等敏感字段，对外分享前务必打码——Formatter 不会自动脱敏。

JSON Formatter 管结构，JWT Decoder 管 token，Regex Tester 管从脏日志里抠 JSON——三件事串起来，500 opaque body 也能在几分钟内定位到字段级问题，而不是和空白符搏斗一下午。

<!-- CONTENT_DEPTH_2026-08-13 -->

## 调试现场备注

先贴最小复现载荷，完整生产 dump 常把真正致命的尾逗号淹没。格式化后重点搜 `null` 与缺字段的差异。同事说「Postman 没问题」时，核对 Content-Type，以及 body 是否被二次字符串化。把一份已知正确的 pretty JSON 放在坏样本旁边对照结构，而不是只盯着高亮括号。