JSON 格式化校验

格式化器并不理解你的数据。它把文本解析成一棵树，再按你要求的空白把树打印回来。机制就这么简单，而这一页所有的行为——包括那些让人意外的——都由它解释。

美化（beautify）加上缩进和换行，让嵌套结构可读；压缩（minify）去掉规范允许去掉的每一个空白字节，适合发请求前或粘贴进配置项之前使用。

因为这一趟是"解析 → 重新打印"，输出**不保证**与输入逐字符相同。空白会被规范化，少数数字写法也会被重写。下面两节具体说明是哪些。

开发者遇到的"格式错误"几乎都是五种从 JavaScript 对象字面量带过来的习惯。JSON 是一门比 JavaScript 小得多的语言，它是刻意不给这些留位置的。

注释。// 和 /* */ 在 JSON 里都不存在。想给配置加注释请用 JSON5、JSONC 或 YAML——JSON 规范没有注释语法，也没有加进去的计划。

尾随逗号。{"a":1,} 是语法错误。JavaScript 允许尾逗号，JSON 不允许。

单引号。键名和字符串值必须用双引号。{'a':1} 直接失败。

不加引号的键。{a:1} 非法，{"a":1} 合法。这是从浏览器控制台复制粘贴最常见的失败原因。

裸的 undefined 和函数。JSON 里没有 undefined、没有 NaN、没有 Infinity、没有函数、没有日期类型。日期只能以字符串或数字的形式传递，undefined 只能省略或改成 null。

解析器会报出第一个失败点的位置，所以错误信息指向的是具体字符，而不是整篇文档。对一份大报文来说，这是一秒改完和找半天的区别。

JSON 规范对数字大小没有限制，但解析它的 JavaScript 引擎有限制。每个数字都会变成 64 位浮点数，超过 2^53 − 1（即 9,007,199,254,740,991）的整数就无法精确表示了。

实际踩坑的不是数量，而是**标识符**。19 位的数据库主键、Twitter 或 Discord 的 snowflake、大额订单号、以最小货币单位存储的金额——凡是"本质是一串数字、却存成了 number"的东西，在被解析的那一刻就会被四舍五入，格式化器再把取整后的值打印给你。

上面算例里的 9007199254740993 回来变成了 9007199254740992。没有任何警告，因为在解析器看来什么都没出错。

正确的修法在数据源头，不在格式化器：大整数 ID 用字符串传——"id": "9007199254740993"——接收端再解析成大整数类型。如果改不了上游，就把格式化结果里 16 位以上的数字全部当成可疑值，跟原始数据核对一遍。

普通对象不会。解析器对非整数键保留插入顺序，也按这个顺序打印，所以粘进去什么结构就得到什么结构。

有两个例外值得知道。第一，看起来像数组下标的键——"0"、"1"、"2"——会被 JavaScript 引擎当成整数键，永远按数字升序排在具名键前面。第二，JSON 规范本身就说对象是**无序**集合，所以即使这个工具保住了顺序，下游系统也没有义务保住。

如果键的顺序对 diff、签名或哈希有意义，不要依赖它。显式排序键（本站有单独的工具），或者比较解析后的结构而不是文本。

它不做 schema 校验。它检查的是"这段文本是不是格式良好的 JSON"，这是语法问题。"age 应该是数字吗"、"这个邮箱真的是邮箱吗"、"必填字段漏了吗"——那些是 schema 问题，需要 JSON Schema 校验器。

它不排序、不过滤、不查询、不比对。键排序、用路径表达式取值、比对两份报文，都是独立的工具，刻意分开，让格式化保持成一个可以信任的单步操作。

它不"修复"坏 JSON。有些工具会猜着补引号和逗号；静默猜测比大声失败更糟，因为被修好的报文可能解析成功，含义却和你原本想的不一样。

它不适合处理超大文件。解析发生在浏览器内存里，几百 MB 的导出数据受限于你的设备，而不是某个服务端配额。