JSON 格式化与校验
粘贴 JSON 立刻美化或压缩，格式错误会指出具体在哪一行哪一列。 带键名排序和非 ASCII 转义——前者让 Git diff 干净，后者让中文在任何环节都不乱码。
输入 JSON
输出
什么时候用得到
- 接口调试：后端返回一坨压缩过的 JSON，美化之后才看得清结构。
- 定位格式错误：少一个逗号、多一个尾逗号、用了单引号——这类错误肉眼很难找，这个工具会直接告诉你第几行第几列。
- 提交配置到 Git：勾上「键名排序」，之后的 diff 只显示真正的值变化，不会因为键顺序变动而整段变红。
- 排查中文乱码：勾上「转义非 ASCII」，把中文变成
\uXXXX，能定位到底是哪一环把编码搞坏了。
四个常见的坑
| 现象 | 原因 | 怎么办 |
|---|---|---|
| 大整数末尾几位变成 0 | 超过 2^53-1（9007199254740991）的整数超出双精度浮点的精确范围 |
后端 ID / 订单号这类长整数，在 JSON 里用字符串传 |
| 加了注释就报错 | JSON 规范不允许注释（RFC 8259） | 改用 JSON5 / JSONC / YAML。很多编辑器「看起来能用」是因为它自己做了容错 |
| 改了配置但没生效 | 键名重复——解析不报错，但只保留最后一个 | 用这个工具格式化一遍，重复的键会在结果里只剩一个，一眼能看出来 |
| 末尾多一个逗号就报错 | JSON 不允许尾逗号（JavaScript 对象字面量允许，所以容易混） | 删掉最后一个逗号 |
这个工具不做什么
它不做 JSON Schema 校验，只做语法校验——也就是「是不是合法 JSON」， 不检查「字段类型对不对」。需要按 schema 验证的话，得用专门的工具或后端校验。
另外，解析后的数字已经变成 JavaScript 的浮点数了。如果你的数据里有超过 2^53 的整数， 美化之后精度就已经丢了——这不是格式化的锅，是 JSON.parse 本身的限制。 真遇到这种情况，建议在服务端就用字符串类型传。
常见问题
超过 2^53 的整数会丢精度吗？
会。JavaScript 的
典型场景是后端的雪花算法 ID、订单号。解决办法是在 JSON 里用字符串传， 或者用支持大整数的解析器（如
JSON.parse 把数字读成双精度浮点，
能精确表示的最大整数是 9007199254740991（253−1）。
再大就会丢失末尾几位，且这个损失是不可逆的。
典型场景是后端的雪花算法 ID、订单号。解决办法是在 JSON 里用字符串传， 或者用支持大整数的解析器（如
json-bigint）。
为什么 JSON 不能写注释？
因为 JSON 的规范（RFC 8259）没有定义注释语法，
严格的解析器会直接报错。
很多编辑器「看起来能用」，是因为它们在解析时自己做了容错——但这份文件拿到别的系统里就会挂。 需要注释的配置建议用 JSON5 / JSONC / YAML。
很多编辑器「看起来能用」，是因为它们在解析时自己做了容错——但这份文件拿到别的系统里就会挂。 需要注释的配置建议用 JSON5 / JSONC / YAML。
JSON 里出现重复的键会怎样？
解析不报错，但只保留最后一个。
这是最隐蔽的一类问题——你改了前面那个键，以为生效了，其实被后面那个覆盖了。
用这个工具格式化一遍：重复的键在输出里只会出现一次。 看到输出比输入短了，就说明有重复。
用这个工具格式化一遍：重复的键在输出里只会出现一次。 看到输出比输入短了，就说明有重复。
为什么需要转义非 ASCII 字符？
中文在链路上被破坏，通常发生在某一段没按 UTF-8 处理的地方——老接口、日志系统、某些数据库连接。
把中文转成
把中文转成
\uXXXX 之后，整份 JSON 只包含 ASCII 字符，
任何环节都不会再改变它。定位编码问题时，这是很有用的手段。
键名排序有什么用？
如果 JSON 是提交到 Git 的配置文件，键的顺序一变，diff 就会显示成整段删除加整段新增，
真正的改动被淹没。
勾上「键名排序」之后，同样的内容会产出同样的顺序，diff 里只会看到真正改了的值。 建议配合编辑器的保存格式化使用。
勾上「键名排序」之后，同样的内容会产出同样的顺序，diff 里只会看到真正改了的值。 建议配合编辑器的保存格式化使用。