← 所有文章

如何格式化、校验和美化 JSON

2026-06-12

简短回答： 把你的 JSON 粘进浏览器内的 JSON 格式化器，点格式化，立刻得到干净、带缩进的输出——如果它无效，则得到一条带行号的清晰报错。它在本地运行，所以你正在调试的那个 API 响应（以及里面的任何 token 或 PII）永远不会离开你的机器。

压缩版 vs 美化版 JSON

同样的数据，两种形态。压缩版 JSON 去掉了每一个空格和换行，让它尽可能小——很适合在网络上传输：

{"id":1,"name":"Milo","roles":["dev"]}

美化（beautified）后的 JSON 加上缩进和换行，好让人真的能读懂：

{
  "id": 1,
  "name": "Milo",
  "roles": ["dev"]
}

你为了阅读和调试而格式化；为了生产而压缩。格式化器两个方向都能做。

在浏览器里格式化和校验

  1. 复制你的 JSON——一个 API 响应、一个配置文件、一行日志，什么都行。
  2. 把它粘进 JSON 格式化器。
  3. 点格式化。有效的 JSON 会带着缩进返回；无效的 JSON 会显示错误，以及解析器卡住的行/列位置。
  4. 修掉被标出来的地方（通常是一个尾随逗号、一个缺失的引号，或者一个误用的 ' 而非 "），然后重新运行。
  5. 又需要把它变小？在粘进生产配置之前压缩它。

校验才是被低估的部分。"第 14 行有意外 token" 远胜过盯着一整面墙的文字，去找那个没闭合的括号。

隐私这一面

你正在调试的 JSON 很少是无害的。API 响应里常常带着 access token、会话 ID、电子邮件地址和其他 PII。很多流行的在线 JSON 工具会把你粘贴的内容发到它们的服务器去格式化——这意味着那个 payload 可能落进它们的日志里。对一个 token 来说，那就是一个有效凭证躺在别人的数据库里。

浏览器内的格式化器在本地解析一切。想要证据？打开 DevTools → Network，粘贴一个 payload，看着——什么都不会发出。和我为 JWT 解码器力推的是同一个把戏：只要它不传输，就不会泄露。

老实说的替代方案

你并不总是需要一个网站：

  • jq——cat data.json | jq . 美化并校验，jq -c . 则压缩。它免费、快，而且一旦你在终端里用顺手了，它就是对的工具。最好的命令行选择，没别的了。
  • Python——python -m json.tool data.json 在大多数机器上零安装就能格式化。
  • 编辑器扩展——VS Code 的 Format Document（Shift+Alt+F）原生处理 JSON。
  • jsonlint.com 及类似站点——它们能用，但会上传你的 JSON 去校验。用假数据没问题，但别用在任何带真实 token 的东西上。

浏览器工具的定位在于这中间地带：比记 jq 过滤器更方便，比一个上传的站点更私密。

常见问题

怎么在无效的 JSON 里找到错误？ 把它粘进一个会报告行和列的校验器里。最常见的元凶是尾随逗号、用单引号代替双引号、以及没加引号的键——JSON 这三样全都禁止。

JSON 和 JavaScript 对象有什么区别？ JSON 更严格：键必须是双引号字符串，不能有尾随逗号，不能有注释，不能有函数。有效的 JSON 是有效的 JS，但反过来不成立。

我应该把压缩版还是美化版 JSON 提交到仓库？ 几乎总是美化版——可读的 diff 比在版本控制里省下那几个字节重要得多。改成在构建/部署时压缩。

我能把 JSON 转成其他格式吗？ 可以——表格数据试试 CSV 转 JSON，要在配置格式间互转就用 YAML/JSON，两者都在浏览器里完成。

— Milo 🐨