摘要：JSON 拥有一套小而严格的语法——那些会破坏解析器的错误（多余的逗号、没有引号的键、单引号）在压缩数据中不可见，但格式化后一目了然。了解真正的语法规则，能把"API 返回了一个错误"变成两秒钟就能解决的问题。可搭配 Encoding Converter、Character Counter、Text Difference 和 AI Hidden Characters 一起使用本指南。
格式化 JSON 是指添加空白和缩进，使其结构可读；校验则是检查该结构是否真正遵循 RFC 8259 中定义的语法。压缩后的 JSON——API 实际传输的紧凑、无空白形式——是正确的但不可读；格式化工具在不改变数据的情况下恢复其可读格式。
真正重要的语法规则
JSON 的键必须是双引号括起来的字符串——{name: "值"} 是无效的，只有 {"name": "值"} 才能被正确解析。单引号对字符串或键永远无效，这与 JavaScript 对象字面量不同，JSON 的语法故意做了这样的限制。数组或对象中最后一个元素后的多余逗号——["a", "b",]——是无效的 JSON，尽管在其他一些语言里这是无害的（甚至按惯例是必需的），这也是手工编辑的 JSON 无法解析的最常见原因之一。
为什么"看起来对"不等于有效
一份 JSON 文档在视觉上可能与有效文档没有区别，却依然解析失败——一个大型嵌套结构末尾缺失的闭合花括号、一个从文字处理软件粘贴过来的弯引号（“）而不是直引号 "，或者一个游离的注释（JSON 完全没有注释语法，不像 JSON5 或 JSONC）都会让严格的解析器失败，而乍一看却都显得没问题。这正是为什么先格式化再查看会有帮助：正确的缩进会打破预期的嵌套模式，从而让未闭合的括号在视觉上一目了然。
格式化与模式校验
格式化工具只检查 JSON 是否在语法上有效——括号是否平衡、字符串引号是否正确、没有多余的逗号。它不检查数据本身是否合理：一个本应是数字的字段实际上是不是字符串，或者是否缺少必需的字段。那是另一项独立的检查，由 JSON Schema 校验来处理，它根据模式定义检查结构和类型，而不只是检查 JSON 本身格式是否规范。
处理混乱或损坏 JSON 的工作流程
- 先把原始 JSON——无论压缩、损坏还是其他情况——粘贴到格式化工具中。
- 如果能解析，检查缩进后的结构，找到你实际要找的字段或值。
- 如果解析失败，先检查错误位置：大多数解析器会报告一个行号/列号，通常直接指向缺失的逗号、括号或引号。
- 当来源是手工输入或从非代码编辑器粘贴过来时，特别留意多余的逗号和印刷体引号。
应避免的常见错误
- 假设看起来有效的缩进就意味着 JSON 有效——格式化和解析是两个独立的步骤。
- 出于 JavaScript 或 Python 的习惯而添加多余的逗号，在那些语言中它经常被容忍。
- 从文字处理软件粘贴 JSON，结果得到弯曲的印刷体引号而不是直角引号。
- 把"格式化时没有报错"和"符合 API 期望的模式"混为一谈——这是两种不同的检查。
大多数 JSON 错误都是特定位置上的一个特定字符——格式化工具真正的价值，是让那个位置变得可见，而不是让你去扫描一整行不间断的文本来寻找它。