JSON 格式化 / 压缩 / 校验

JSON 校验：七个最常见的语法错误与它们的真实报错

格式化与压缩在做什么

JSON 规范把空白字符定义为语法上无意义的。花括号前后的换行、冒号后的空格、任意数量的缩进，解析器都会忽略。所以：

• 格式化（beautify）：按层级插入换行和缩进，让结构可读。这是给人看的。
• 压缩（minify）：删掉所有语法上可省略的空白，换取更小的体积。这是给机器传的。

两者都不改变数据本身——唯一的例外是数字的书写形式：1.0 会被写成 1，1e3 会被写成 1000，-0 会变成 0。它们数值相等（-0 在多数语言里也等价），但如果下游是按字符串精确比对，这个差异会显现出来。

压缩能省多少？通常 10%~30%。但要注意：如果你在 HTTP 上开了 gzip/brotli，压缩 JSON 的额外收益就很小了——压缩算法本身就会消掉重复的空白与键名。压缩 JSON 真正有价值的场景是：内嵌在 HTML/JS 里的数据、写进存储或消息队列的消息体、以及有体积上限的地方（URL、Cookie、LocalStorage）。

另外：键的顺序不影响语义。规范明确对象是无序的键值集合。所以压缩/格式化后键的排列顺序变化，不构成数据变化。

七个最常见的语法错误

第 4 条值得展开：注释在配置文件里很常见，但标准 JSON 不允许。带有注释的格式有各自的名字——JSON5（允许注释、单引号、尾随逗号、无引号键、十六进制数字）和 JSONC（JSON with Comments，VS Code 的 settings.json、TypeScript 的 tsconfig.json 用的就是它）。它们是 JSON 的超集，标准 JSON 解析器读不了。如果你的配置需要注释，先确认读取方支持哪种方言。

两个不会报错但更危险的坑

重复键。这段 JSON 是合法且能解析的：{"a":1,"a":2}。规范对重复键的行为没有定义，而 JSON.parse 的实现是保留最后一个，静默丢弃前面的值。这意味着一个手写或拼接错误产生的重复键，会无声无息地把数据改掉——没有报错，没有警告。排查"数据莫名其妙不对"时，这是一个值得专门检查的点。

大整数精度丢失。JSON 的数字在 JavaScript 里是 IEEE 754 双精度浮点，能精确表示整数的上限是 2⁵³-1，即 9007199254740991（16 位数字）。超过这个范围就会丢精度：

{"id": 9007199254740993} 解析后再序列化，会变成 9007199254740992。

这不是工具的问题，是 JSON 数字模型与 JS 数字类型共同的限制。真实影响是雪花算法 ID、Twitter/X 的 post ID、Discord 的 snowflake、大额金额以分为单位存储——这些都长期超过 16 位。正确做法是让后端把这类 ID 序列化成字符串，而不是数字。如果无法改后端，就只能在解析时用支持大数的解析器，或者用正则先把这些字段保护起来。

校验之外还要看什么

语法合法不等于结构正确。{"user":{"name":123}} 是合法 JSON，但如果约定 name 是字符串，它就是错的。语法层校验（本工具做的）和结构层校验（JSON Schema、Zod、pydantic 这类）是两件事。

另外，不要用 eval() 去解析 JSON。JSON 是 JavaScript 语法的一个子集，所以 eval 能"解析"它——但也会执行任何夹带的代码。JSON.parse 只接受数据，不接受表达式，这是它存在的意义。

工具怎么用

1. 把 JSON 粘进输入框。
2. 点格式化得到缩进版本，点压缩得到单行版本。
3. 如果语法有错，工具会指出出错的位置（行号与列号）和原因。定位边界上的逗号或引号最快的方法就是看这个位置。

解析与格式化全部在浏览器本地完成，接口返回的敏感数据不会离开你的设备。