如何格式化与校验 JSON：一份实用的 JSON Formatter 指南

JSON 全称 JavaScript Object Notation，是一种承载结构化数据的轻量文本格式。API 用它通信，配置文件用它书写，数据导出也把它当作各系统之间唯一的公约数——哪怕这些系统在别的方面毫无共同之处。它之所以流行，是因为对机器和人都友好：对象放进大括号，数组放进方括号，键映射到值，不需要任何 schema，打开文件就能看懂它的结构。

但可读并不等于宽容。JSON 很严格，文档里任何位置混进一个多余字符，整份内容就解析失败。它没有部分恢复机制，也不会「尽力」去读那些没问题的片段。解析器一旦无法完整校验全文，就会把整份文档全部拒绝。所以修好非法 JSON，说白了就是记住这套为数不多的规则，再拿你的文件逐条对照。

排在首位的是尾逗号。对象或数组最后一项后面跟一个逗号，JavaScript、Python 和大多数配置格式都能容忍，于是它总是悄悄溜进 JSON，然后每一次都被无情拒绝。紧随其后的是用单引号代替双引号，以及键没加引号。这两种写法在 JavaScript 对象字面量里完全合法，正因如此，当有人手动改 payload，或者从浏览器控制台里复制一个值出来时，它们就会渗进 JSON。

接下来是注释。这一点常常让人意外，因为几乎所有跟 JSON 沾边的工具都接受注释，而严格意义上的 JSON 并不接受：双斜杠行注释不行，块注释也不行。再往后，检查括号是否缺失或不配对，字符串值里有没有未转义的双引号或换行（这两者前面都必须加反斜杠），以及有没有出现 NaN、Infinity 这类特殊值——它们在多数语言里是货真价实的数值，在 JSON 里却没有任何合法写法。拿这份清单去核对出问题的文档，几乎每次都能揪出元凶。

JSON 格式化器（也常被叫作 JSON 美化器）会用统一的缩进和换行重新排布文档，让嵌套的数据变得可读。一份原本挤成一整行的 API 响应，会变成你真正能扫一眼就看懂的样子，结构性问题也随之浮出水面：一个孤立无援的括号、一个待在错误层级的值、一个提前两层就闭合的对象。美化不只是外观上的整理，它同样是调试手段。

压缩则是它的镜像操作：去掉所有不必要的空白，把内容压成一行，从而减小体积。当文档要在每一次请求时通过网络传输，这一点就格外要紧。关键在于，这两种操作都完整保留了数据本身。对 JSON 解析器来说，token 之间的空白没有任何含义，所以美化后的文档和压缩后的文档其实是同一份文档，区别只在人的可读性和字节数。

JSON 校验器回答的问题比格式化器更严苛：这份文档在语法上到底合不合法？好的校验器会完整解析全文，并给出第一个语法错误的精确位置，精确到行号和列号。正是这个细节，区分开了一个有用的工具和一个只会耸肩的工具。只告诉你「文档非法」，对谁都没帮助；告诉你「第 47 行第 12 列出现了意外的 token」，你就有了下手的地方。

整个流程是反复迭代的：修掉这个错误，重新校验，再来一轮。JSON 解析器通常一碰到问题就停下，所以哪怕文档里藏了好几处毛病，单次校验也可能只暴露一个。如果你补掉一个尾逗号，校验器马上又报出新问题，那并不说明你把文件改坏了——你只是搬开了挡住下一个错误的障碍物。每迭代一轮，你就离一份能干净解析的文档更近一步。

我们的 JSON 格式化器把这两件事放在了一处。把 JSON 粘贴进去，它会立刻完成美化或压缩并做校验；解析失败时，还会给出第一个语法错误的位置。不用装任何东西，不用编辑器插件，也没有需要干等的网络往返。

值得多说两句的正是「往返」这件事——因为压根就没有往返。解析全部发生在你的浏览器里，数据从不会被发往服务器。当你屏幕上的 JSON 含有令牌、API 密钥、个人记录或内部 API 响应时，这一点至关重要，而这恰恰描述了开发者真正需要调试的绝大部分 JSON。把生产环境的 payload 粘进某个来路不明的网站，是一次很小却会被记很久的泄漏；同样的活儿放在本地做，文档就永远不会离开你的机器。