JSON 在线格式化：缩进怎么选、压缩后为什么变大

格式化只做一件事：把没有换行的 JSON 按层级重新排版。真正影响结果的是缩进宽度——4 空格适合阅读和代码评审，2 空格适合塞进配置文件，Tab 适合已在用 Tab 的团队。格式化不会改变任何数据，但会让文件明显变大，这是换行与缩进占的字节。

先校验再格式化，别反过来

格式化的前提是 JSON 语法合法。如果原文少一个逗号或多一个尾逗号，格式化器只能猜你想表达什么，输出的排版会把错误藏进缩进里，反而更难找。

正确顺序是：先校验，确认语法通过（工具会给出中文错误原因与精确的行号、列号，并在原文对应位置插入指示符），再格式化。校验失败时输入框内容原样保留，改完再试即可，不会丢输入。

缩进宽度怎么选

• 4 空格：默认值。层级差最明显，适合贴进文档、代码评审、给不熟悉这份数据的人看。
• 2 空格：多数前端项目的 .eslintrc / tsconfig / package.json 风格，适合直接粘回工程文件。
• Tab：跟已有用 Tab 的仓库保持一致。混用空格和 Tab 在 diff 里会出现整行变更。
• 1 或 3 空格：深嵌套（5 层以上）时用窄缩进，横向不会被推到屏幕外。

选哪个不影响正确性，只影响「谁来看这份文件」。同一份数据在不同场景用不同缩进是正常的，工具不记忆你的选择，每次进来都是默认值。

格式化后体积变大是正常的

格式化只增加两类字节：每层级的缩进，和每个键值对之间的换行。一个 10KB 的单行 JSON 格式化成 4 空格后可能变成 15–20KB，嵌套越深增幅越大。

所以 要传输、要存进 localStorage、要放进 URL 参数时用压缩（一键压成单行，去掉全部非必要空白），要人读时用格式化。压缩不会删掉字符串内部的空格——那是数据的一部分。

大文件与超长数字

MB 级文本可以在毫秒级完成解析，树形视图按需渲染节点，不会一次性创建海量 DOM；超大结果会自动退化为纯文本展示，避免页面卡死。

另一类容易踩的坑是超长整数：超过 2⁵³ 的整数（如 12345678901234567890）若用普通 JSON.parse 会先转成 double 再输出，末尾几位被改掉。这个工具保留数字的原始文本，输入与输出逐位一致，订单号、雪花 ID、银行卡号这类字段不会被悄悄改值。