使用说明

1. 把 JSON 粘贴到左侧输入框，或点击「上传」选择本地文件。
2. 点击「格式化」生成带缩进的美化 JSON；点击「压缩」生成单行 JSON，方便传输或嵌入代码。
3. 需要稳定 diff 或审查配置变化时，勾选「键名排序」；遇到非标准 JSON（单引号、末尾逗号）可勾选「容错修复」。

典型使用场景

• API 调试：从浏览器 Network 面板或 Postman 复制响应 JSON，粘贴到左侧，快速格式化并排查字段是否缺失或类型不一致。
• 日志排查：很多服务把结构化日志写成一行 JSON，先用「压缩」确认原始数据，再用「格式化」展开，配合「键名排序」对比多条日志的差异。
• 配置文件管理：编辑复杂的应用配置（如前端构建配置、服务端特性开关）时，用格式化 + 校验，确保 JSON 结构合法，避免因漏逗号 / 漏引号导致应用启动失败。
• 团队 Code Review：Review 其他同学提交的大 JSON 配置时，把旧版本和新版本都格式化 + 排序，再在 Git / diff 工具里对比，更容易看出真正变更的字段。

示例：常见 JSON 结构

下面是一个典型的接口响应示例，你可以复制到左侧尝试不同操作：

{
  "code": 0,
  "message": "ok",
  "data": {
    "user": {
      "id": 123,
      "name": "Alice",
      "roles": ["admin", "editor"]
    },
    "meta": {
      "requestId": "f3b8a1de-12ab-4c90-9f38-8888abcd0001",
      "timestamp": 1739097600000
    }
  }
}

你可以尝试：

• 去掉部分逗号或引号，然后点击「校验」，观察错误提示。
• 勾选「容错修复」，再点击「格式化」，看看工具能自动修复到什么程度。
• 勾选「键名排序」，对比排序前后的变化，体会在做 diff 或审查配置时的优势。

编写 JSON 的最佳实践

• 保持字段命名一致：同一类对象尽量使用统一的字段名（如统一用 userId 而不是有时 id 有时 uid），方便前后端协作和日志检索。
• 避免嵌套过深：超过 4–5 层的嵌套会显著增加调试成本，可以适当拆分为多个字段或子对象。
• 显式写出可选字段：对于需要长期维护的配置，建议即便是可选字段，也在 JSON 中给出默认值和注释说明（可在代码中维护注释或文档说明）。
• 区分机器字段和展示字段：例如同时保留 status（用于代码判断的枚举）和 statusText（用于展示的文案），避免前端在多个页面到处写硬编码。
• 提交前先格式化 + 校验：无论是 API Mock 数据还是配置文件，提交到仓库前都可以用本工具格式化和校验一遍，减少线上因 JSON 语法错误导致的故障。

常见错误与排查思路

• 单引号代替双引号：标准 JSON 只支持双引号，后端语言中的对象字面量有时支持单引号，但这在 JSON 中是不允许的，可以先开启「容错修复」。
• 多写或少写逗号：列表或对象最后一个元素后面多写一个逗号，是最常见的错误之一。利用本工具的错误提示，可以快速定位到出问题的行号。
• 键名未加引号：如 { id: 1 } 在很多语言里是合法的对象字面量，但在 JSON 中必须写成 { "id": 1 }。
• 数字精度问题：JavaScript 中大整数可能会有精度问题，建议对特别大的 ID 或金额使用字符串类型，并在业务层做解析。

常见问题（FAQ）