JSON 美化

美化 JSON 是一次显示层面的决定，而不是一次编辑。解析器把您的文本读成一个值，格式化器再把这个值带着换行和缩进写回去。字节变了，数据没有变。这个区别很要紧，因为正是它让您可以不假思索地把格式化后的文档粘回生产环境：对象的键序按写入时保留，数字保持其值，字符串保持其确切内容（包括引号内部的空白），没有任何东西被重新排序或丢弃。

整个过程都在您浏览器的标签页里完成。文本由页面中已加载的 JavaScript 引擎解析、格式化，再写回编辑器。没有任何网络请求把它带往别处，而这一点您可以验证而不必相信：加载页面，断开网络连接，再格式化一次。它照样可用，因为所需的一切都已经在这里了。

这种架构是重点而非细节。人们要格式化的 JSON 几乎从来不是教学示例，而是正在调试的一个 API 响应，其中经常携带访问令牌、会话标识、客户邮箱、内部数据库 ID，以及一个私有 API 的结构。这些恰恰是不该变成别人请求日志里一行记录的东西，而一个从未收到它们的工具，也就没有什么可记录的。

有两个格式化选择值得郑重做出。缩进宽度只是外观，但与您代码库保持一致会影响 diff：JavaScript 项目通常用两个空格，其他环境常用四个，若您的检查工具要求则用制表符。按字母顺序排序键则是更重的决定。它让两份文档可以一眼比较，同时也破坏了作者可能有意安排的顺序，所以比较时排序一份副本，交付时让原件保持原样。

格式化做不到的是修复一份本就无效的 JSON。如果解析器拒绝，那就是语法错误，再怎么重新排版也掩盖不了。尾随逗号、用单引号包裹字符串、不加引号的键、注释以及 NaN，在手写配置里都很常见，而它们都不是合法的 JSON。校验器会指出位置；一旦知道该看哪里，修复往往只是一个字符的事。

一个实用习惯：先格式化再比较，而不是反过来。两份仅空白不同的文档会产生充满噪声的 diff，把唯一真正改动的那一行淹没其中。先把两者整理成同一形状，diff 就变成几秒钟就能读完的东西，而这正是这个工具存在的全部理由。