JSON 포맷 모범 사례

同一份 JSON：开发时要 2 空格缩进方便 Code Review，上线却要 minify 省带宽——格式化策略选错，要么 diff 看不清，要么响应体大一圈。

本文面向前后端与测试工程师，讲解 JSON 格式化的目的、开发/生产不同策略、5 步推荐工作流，以及校验、排序键、JSON5 等常见误区。阅读完成后，你可以用 JSON 工具箱在浏览器本地完成格式化与压缩——数据不上传。

为什么格式化策略很重要

格式化改变的是「呈现方式」，不是数据语义。但呈现方式直接影响：Git diff 是否可读、日志是否便于 grep、HTTP 响应体积与首包时间。

我们见过团队把 minify 后的 JSON 提交进仓库，导致 PR 无法 review；也见过生产接口返回未压缩的 500KB 美化 JSON，拖慢移动端弱网体验。分场景处理是基本素养。

JSON 格式化（Pretty Print）是在不改变数据的前提下，插入缩进与换行，使结构层级一目了然。压缩（Minify）则移除所有非必要空白，得到单行或最短表示。

压缩单行：

{"user":{"id":1,"name":"Alice"},"tags":["dev","json"]}

格式化后（2 空格）：

{
  "user": {
    "id": 1,
    "name": "Alice"
  },
  "tags": ["dev", "json"]
}

含语法错误的文本无法正确格式化。推荐流程：粘贴 → 校验 → 格式化 → 复制。

本工具仅支持标准 JSON：无双引号键名、无尾逗号、无注释。若从 JS 对象复制，请先转为合法 JSON。

超过 2MB 的 JSON 在浏览器中格式化可能卡顿。建议用 CLI（jq）或按子树拆分处理。

格式化会改变数据内容吗？

不会。仅改变空白与换行，解析后的对象与压缩前语义相同。

2 空格和 4 空格选哪个？

无绝对标准。前端项目多与 Prettier 默认 2 空格一致；Java 等后端项目常见 4 空格。团队内统一即可。

键排序有什么用？

当两份 JSON 内容相同但键顺序不同时，排序后 diff 更清晰。注意不要改变有顺序要求的业务数组。

压缩后的 JSON 还能还原成可读格式吗？

可以。对 minify 结果再次执行格式化即可，数据不会丢失。

数据会上传到服务器吗？

不会。JSON 工具箱纯前端处理，适合粘贴含内网字段的样例（敏感信息仍建议脱敏）。

为什么格式化失败提示语法错误？

常见原因：尾逗号、单引号字符串、未转义换行、或使用 JSON 不支持的注释。请先用校验工具定位行号。

格式化是低成本提升协作效率的手段：开发可读、生产精简、操作前先校验。把「校验 → 格式化 → 使用」固化为团队习惯，可减少低级 JSON 错误进入仓库或线上。

建议在编辑器中配置保存时格式化，并在 CI 中对关键 fixture 做 JSON 语法检查；大版本发布前配合 Diff 工具审查接口样例变更。