JSON 格式化实战:美化、压缩、纠错与本地隐私保护

写后端、调接口、改配置文件,几乎天天要跟 JSON 打交道。它结构简单,但简单到一个尾逗号就能让整段数据解析失败。这篇文章把日常最高频的几件事讲透:什么时候该美化、什么时候该压缩,常见语法错误怎么定位,缩进和转义怎么取舍,以及为什么处理敏感数据时,本地运行比在线服务更让人安心。

美化和压缩,是同一份数据的两副面孔

美化(beautify)就是给 JSON 加上换行和缩进,让层级关系一眼看清,适合阅读和 debug。压缩(minify)正相反,去掉所有非必要的空白字符,让数据体积变小,适合塞进 URL 参数、curl 命令体,或者存进数据库的一个字段里。

两者底层用的都是浏览器内置的 JSON.parse 和 JSON.stringify,先把字符串解析成对象,再按你要的格式重新序列化。所以无论美化还是压缩,前提都是这段 JSON 语法本身合法。语法不过,两个方向都走不通。

举个真实例子。下面这段压缩过的接口返回,挤在一行里根本读不动:

{"user":{"id":42,"name":"李雷","roles":["admin","editor"]},"active":true,"quota":{"used":87,"limit":100}}

美化成 2 空格缩进后,层级结构立刻清晰:

{
  "user": {
    "id": 42,
    "name": "李雷",
    "roles": [
      "admin",
      "editor"
    ]
  },
  "active": true,
  "quota": {
    "used": 87,
    "limit": 100
  }
}

同一份数据,换个排版,可读性天差地别。你可以直接在 /zh/t/json-formatter/ 里粘贴试一下,左边贴原文,右边即时出结果。

三类最坑人的语法错误

JSON 的语法规则其实很死板,这恰恰是踩坑的高发区。因为很多语言的对象字面量比 JSON 宽松,你写惯了就容易把习惯带进来。

第一类是尾随逗号。数组或对象的最后一个元素后面多一个逗号,Node、Python、现代 JS 都能容忍,但标准 JSON 严格禁止。文件在你编辑器里跑得好好的,拿到别处一解析就报错,十有八九是它。

第二类是单引号。JSON 规范里字符串和键名只允许用双引号,单引号一律非法。从 Python 的 print(dict) 或者某些日志里复制出来的数据最容易中招,满眼的单引号需要整体替换成双引号。

第三类是注释。JSON 标准不支持 // 和 /* */ 注释。tsconfig.json 这类文件能写注释,是因为 TypeScript 用的是 JSONC(带注释的 JSON)这个超集,标准解析器并不认。

这些规则不是工具的脾气,而是写进了 RFC 8259(《The JavaScript Object Notation Data Interchange Format》,IETF 2017 年发布的现行标准)。规范里白纸黑字写明:字符串必须由双引号包裹,对象和数组成员之间用逗号分隔且结尾不带逗号,整个语法里也没有给注释留位置。所以严格来说,带注释、带尾逗号的"JSON"根本不是 JSON。一个好的校验器会把出错的行号和列号直接标给你,而不是只甩一句笼统的 SyntaxError,省去你从头数括号的功夫。

缩进和转义:两个容易忽略的细节

缩进通常在 2 空格、4 空格、Tab 之间选。前端项目和 npm 生态偏爱 2 空格,不少后端规范用 4 空格,而 Tab 的好处是每个人能在自己编辑器里调成喜欢的宽度。选哪个不重要,和团队保持一致才重要,免得 diff 里全是空白字符的噪音。

转义是另一个常被问到的点。中文、emoji 这类非 ASCII 字符,JSON.stringify 默认会写成 \uXXXX 的转义序列,比如"李雷"会变成一串 李雷。这是完全合法的 JSON,任何解析器都能正确还原,只是人读起来费劲。要清楚:转义改变的只是 JSON 的编码形式,字符串的真实值一个字节都没动。

如果你的工作流不止 JSON,还涉及 YAML 配置,可以顺手看看 /zh/t/yaml-to-json/,把 YAML 转成 JSON 再格式化,是 CI 配置调试里很常见的一步。

我自己的一个习惯

我手写完一段 tsconfig.json 扩展或者新加的 webhook 配置,从不直接跑构建。我会先把它粘进格式化工具,确认能正常 parse,再扫一眼层级对不对,然后才去跑 pnpm tsc。在 linter 之前先把多余的逗号、漏掉的引号抓出来,每次省下的不只是一分钟,更省下满屏的解析器报错刷屏。这个动作几乎成了肌肉记忆,排查问题的成本被压到了最前面,越早发现越便宜。

为什么本地处理这件事值得较真

很多在线 JSON 工具会把你粘贴的内容发到它们的服务器去处理。但你粘的是什么?很可能是带着 API token 的接口返回、内部服务的端点地址、甚至生产环境的用户数据。这些一旦离开你的机器,你就失去了控制权。

纯前端的工具不存在这个问题。数据走的是浏览器内置的 JSON 引擎,一个字节都不发出去。不信可以打开 DevTools 的 Network 面板,一边格式化一边看,不会有任何请求带着你的 payload。粘 token、粘内部接口、粘生产响应,全程都待在你这个标签页里,关掉就什么都不剩。处理敏感数据时,这一条比快几毫秒重要得多。

小结

JSON 格式化看着是小事,用顺了能实实在在省时间:美化用来读、压缩用来传,尾逗号和单引号是报错重灾区,缩进求统一、转义不改值,而本地处理则守住了敏感数据的底线。把这几点变成习惯,你跟 JSON 的每次交手都会更利落。

Made by Toolora · Updated 2026-06-13