JSON 格式化与缩进：Tab 还是空格？最佳实践指南

JSON 标准对空白字符的规定

JSON 语法中的空格、换行、Tab 仅用于分隔 token，不影响语义。

因此 { "a":1 } 与带多行缩进的写法解析结果相同；选择缩进风格纯属可读性与团队规范问题。

Tab vs 空格：怎么选？

推荐空格：跨编辑器显示一致，Git diff 更直观，与 Prettier、ESLint 默认行为一致。

Tab 在 JSON 中合法，但不同 tab 宽度会导致对齐混乱，开源项目与 API 文档中较少采用。

若团队已有 .editorconfig 规定 indent_style = space，JSON 应跟随同一规则。

2 空格 vs 4 空格

2 空格：前端、Node.js、package.json 生态最常见；嵌套深时仍能保持行宽合理。

4 空格：部分 Java、Python 项目配置文件更常见。

关键是一致：同一仓库内不要混用 2 与 4。本站默认可读性格式化为 2 空格。

{
  "user": {
    "name": "Alice",
    "roles": ["admin", "editor"]
  }
}

美化（Pretty Print）适用场景

调试接口响应、编写示例文档、人工编辑配置文件。

Code Review 时格式化后再提交，diff 只反映实质变更。

压缩（Minify）适用场景

生产环境 HTTP 传输、写入消息队列、嵌入 HTML 减少体积。

压缩后不可读，请勿直接手工编辑压缩 JSON；应保留一份格式化源文件或从数据库/API 重新生成。

{"user":{"name":"Alice","roles":["admin","editor"]}}

团队规范建议

仓库根目录 .editorconfig 声明 json 文件 indent_size。

CI 中可选：对提交的 .json 样例运行 json.tool 或 jq 确保可解析。

对外 API 文档示例统一 2 空格；日志存储可用压缩格式节省空间。