开发者 JSON 格式化和验证指南

JSON 是互联网默认的数据格式，也特别擅长以毫无帮助的方式报错。少一个逗号、多一个尾逗号，或者从文档里粘过来的一个弯引号，解析器报的位置往往离真正的问题隔了好几行。多数时候 JSON 排查不难，只是慢，解决办法就是先让结构可见。

造成大多数失败的语法错误

• 尾逗号。JavaScript 的对象字面量容忍它，JSON 不容忍，这是解析失败最常见的原因。
• 用单引号代替双引号。JSON 要求所有键和字符串值都用双引号。
• 键没加引号。键永远是字符串，即使它看起来像个标识符。
• 从文字处理软件粘来的弯引号。屏幕上看不出区别，但那是完全不同的字符。
• 注释。JSON 完全没有注释语法。需要注释就用 JSON5、JSONC，或者单独维护一份 schema 文档。
• NaN、Infinity、undefined 都不是合法的 JSON 值。用 null，或者把这种状态单独编码。

格式化是排查工具，不只是好看

美化输出会加缩进，让嵌套结构可见。这很重要，因为相当一部分 bug 是结构问题而不是语法问题：某个值放高了一层、本该是对象的地方写成了数组，或者两个本该合并的兄弟键。结构一旦可读，这些错误一眼就能看出来。多数格式化工具还会给出失败的确切字符位置，比「意外的 token」这种通用报错有用得多。

处理来自接口的 JSON

1. 先把原始响应粘进来，确认它能解析。不要拿已经不合法的数据去调客户端代码。
2. 体积敏感时，发送前压缩成一行。在移动网络下，空白可能占大体积响应里可观的比例。
3. 同事需要用表格看数据时转成 CSV。记住 CSV 没有嵌套概念：要主动拍平结构，别交给转换器猜。
4. 要区分 null 和「字段缺失」。显式设为 null 和根本没返回这个字段，含义不同。
5. 在测试套件里做 schema 校验，而不是只在生产日志里发现问题。

大文件处理：别把浏览器卡死

超过大约 10 MB 的文件，任何浏览器编辑器都会吃力。真正的瓶颈通常是超长单行：一行两百万个字符，即使解析瞬间完成，渲染也会把界面卡住。如果你经常处理这种量级的数据，先压缩成一行看体积是不是花在空白上；然后只格式化你要排查的那一段，而不是整份文档。