JSON 格式化怎么用：5 个常见场景

JSON 是接口通信的事实标准，但它对机器友好、对人极不友好。一段 2000 字符的响应体挤在一行里，想找一个字段值几乎不可能。下面这 5 个场景是我日常遇到最多的。

场景一：接口返回看不懂，先格式化再读

抓包或从浏览器 Network 面板复制出来的 JSON 通常是最紧凑的形式。粘进 JSON 格式化工具，点一下「格式化」，缩进、换行、颜色一次到位，嵌套层级一望即知。

如果只是想快速定位某个字段，用树形视图更快：它把每一层折叠成一个可展开的节点，不用在长文本里翻滚。

场景二：提交前压缩，省带宽也省日志

配置同步、埋点上报这类场景，JSON 会被高频传输。去掉所有空格和换行能省下 20%~40% 的体积。同一个工具的「去空格」按钮做的就是这件事——它只删结构性空白，不会碰字符串内部的空格。

场景三：把 JSON 塞进 JSON，需要转义

有时候要把一段 JSON 当作字符串嵌到另一个 JSON 里，比如写测试用例或构造 GraphQL 变量：

{ "payload": "{\"id\": 1, \"name\": \"demo\"}" }

手工加反斜杠很容易漏。可以直接用工具的「转义」按钮把整段 JSON 转成字符串；反过来从日志里抠出一段被转义的 JSON 时，用「去除转义」还原。

场景四：定位少括号、多逗号这类语法错误

JSON 解析失败时报的错往往只给字符偏移量，不告诉你缺了什么。先格式化，缩进层级会立刻暴露问题——某一层突然多缩进或少缩进，通常就是那里少了或多了符号。

最常见的三类错误：对象属性之间漏逗号、末尾多一个逗号（标准 JSON 不允许尾逗号）、字符串用了单引号（JSON 只认双引号）。

场景五：对比两个版本的接口响应

升级前后同一个接口的返回差异，用肉眼找不现实。把两份 JSON 各自格式化后再用文本对比工具并排比较，改动的字段会被高亮出来。

小结

格式化是为了读，压缩是为了传，转义是为了嵌。搞清楚当前要解决哪个问题，就不会在三个按钮之间犹豫。