如果你经常在用 JSON 格式化工具，应该对这个场景不陌生：复制一段乱七八糟的 JSON，点一下“格式化”，屏幕立马清爽起来。但下一秒，你可能就开始皱眉，缩进怎么是 4 个空格？为什么不是 2 个？或者更激进一点，有人直接上了 Tab。
缩进，看似是小问题，实际却是程序员之间永远争不完的话题。尤其在 JSON 这种结构化数据的场景下，它不仅关乎可读性，还会对性能、文件大小甚至跨平台协作造成影响。
2 空格：紧凑、节省空间
用 2 个空格缩进，往往是前端工程师和 API 文档的偏好。理由很直接：
- 文件更小：每层缩进比 4 空格少一半字符，JSON 文件大时能节省不少体积。
- 视觉紧凑：在小屏幕里看数据时，2 空格不会显得层次过于分散。
但缺点也明显：如果 JSON 层级太深，2 空格在阅读时容易“挤成一坨”，辨识度不够。
4 空格：清晰、传统、安全牌
4 空格缩进几乎成了后端、传统 IDE 的默认选择，比如 Python 社区就是死守 4 空格的阵营。
- 层级更清晰：每一层缩进拉开距离，结构一眼就能看出来。
- 跨人群习惯好：不同语言的程序员切换到 JSON 时，4 空格大概率不需要适应。
问题是，文件体积会比 2 空格大一些，在大 JSON 格式化时，多出的空格其实就是浪费。
Tab：灵活但有“坑”
Tab 派的核心观点是：缩进就是缩进，不应该用空格来假装缩进。理论上 Tab 的好处不少：
- 可定制：不同人可以在 IDE 里把 Tab 显示成 2 空格、4 空格甚至 8 空格。
- 存储更省：文件里就一个
\t，比一堆空格更轻量。
但问题也正是这种“灵活性”带来的：不同编辑器、不同系统的默认 Tab 宽度不一致。你以为是 2 格，别人机器上一看变 8 格，直接毁掉排版。
性能层面：真的有差别吗？
如果只是几十 KB 的 JSON，缩进方式对性能几乎没有差别。但当数据量上百 MB 时，差距就出来了：
- 2 空格 vs 4 空格：解析速度几乎一致，但 4 空格会让文件体积更大，网络传输、磁盘读写上开销更高。
- Tab：文件体积理论上最小，但很多解析器和工具链会先把 Tab 转成空格，结果未必比 2 空格轻。
所以在 JSON 格式化 工具的实现上，很多都默认 2 空格，因为它是“兼顾体积和可读性”的折中。
实际选择：场景导向更重要
- 团队协作：建议统一成 2 或 4 空格，避免 Tab 引起跨环境显示不一致。
- API 调试：2 空格更紧凑，传输更快，特别是接口返回大 JSON 时。
- 日志/存档：4 空格更清晰，方便人工排查问题。
- 内部存储：干脆不要缩进，用压缩 JSON（
JSON.stringify(obj)的第二个参数为null，第三个参数为空），机器解析最快。
小结
缩进是开发者的老话题，2 空格 vs 4 空格 vs Tab，其实没有“绝对正确”的答案。更多时候是权衡：要么文件小、紧凑，要么阅读舒服、清晰。
如果你只是用 JSON 格式化工具 来临时查看数据，那我建议直接用 2 空格，既省眼睛，也省存储。如果是团队约定，就乖乖跟随规范，不然代码审查的时候，争的不是业务，而是缩进。
你平时在用 JSON 格式化时，习惯 2 空格、4 空格，还是 Tab？
