JSON 格式化：美化、压缩与语法错误定位

什么时候真的需要格式化

接口返回的 JSON 被压成一整行，看不清字段层级和嵌套关系。展开后能一眼看出某个字段是在对象里，还是在数组元素里。

提交前自检：多余的尾逗号、没加引号的 key、字符串里未转义的换行、写错的括号，这些都属于「人能看出来但解析器才权威」的问题，让 JSON.parse 报位置比肉眼扫快。

反过来，把调试用的多行 JSON 压成一行，塞进环境变量、命令行参数或单行配置项时也用得上。

• 展开压成一行的 API 响应
• 提交前校验语法
• 压缩成一行放进配置
• 对比两个版本的结构差异

怎么做才不出错

美化本质是 JSON.parse 再 JSON.stringify，缩进用 2 个空格。这意味着输出是「解析后的结果」，不是原文的排版：key 顺序可能被调整，数字格式会被规范化，空白排版会按工具重新生成。

报错里的 position 是浏览器 JSON.parse 给出的字符偏移，Chrome/Edge 里从 0 开始，通常还给出行和列。它指向解析器停下的位置，不一定是真正错的那个字符：漏逗号常在下一个 key 处报错，多余的尾逗号常在闭括号处报错，所以要从报错位置往前看几行。

JSON 是严格格式：注释、单引号、尾逗号、NaN、undefined 都不合法，会直接报错。带注释的配置是 JSONC，别拿 JSON 工具去洗；想要宽松解析得用专门的 JSON5 或 JSONC 解析器。

大整数会丢精度。JSON.parse 把所有数字转成 IEEE-754 双精度浮点数，超过 2^53−1（9007199254740991）的整数不再精确，例如 1234567890123456789 会被格式化成 1234567890123456800。这是 JSON.parse 的限制，不是格式化造成的。订单号、雪花 ID 请在源头存成字符串。

大文件要注意内存。几百 KB 到几 MB 通常即时完成；几十 MB 的文件可能会明显卡顿，内存较小的设备上甚至失败，因为原文、解析后的对象、序列化结果会同时留在内存里。整个过程不上传，卡住只影响当前标签页，刷新即可恢复。

• 缩进 2 空格，输出是解析后的结果
• position 从 0 开始，往前看几行
• 注释、单引号、尾逗号一律报错
• 超过 2^53−1 的整数会变，ID 用字符串

替代方案与局限

命令行 jq 更适合大文件和批处理：它是流式的，内存占用小，还能直接取字段、过滤、做转换。代价是要装工具、记语法。

只想看某个字段时，浏览器 devtools 的 Network → Response 里搜索字段名更快，不必把整段 JSON 复制出来。

需要保留大整数精度，用支持 BigInt 的解析器或把数字当字符串处理；需要注释和尾逗号，用 JSON5 或 JSONC；需要校验结构，用 JSON Schema。

本工具不做 schema 校验，也不保留原始数字文本；它只负责美化、压缩和报错定位。

• 大文件、批处理 → jq
• 只看某个字段 → devtools
• 大整数 → BigInt 解析器或字符串
• 注释 → JSON5 或 JSONC