JSON 格式验证怎么做?常见报错原因与修复方法

JSON 格式验证的核心动作只有一步：把待检查的文本交给一个符合 JSON 规范的解析器，看它能否完整解析。能解析通过，说明这段文本是合法 JSON；解析中断并抛出错误，说明存在语法问题，错误信息通常会指出出错的位置和原因。在 JSON.cn 这类在线工具里，把内容粘贴进输入框即可得到验证结果，适合快速确认一段配置、接口返回值或日志片段是否合法。验证通过后再做格式化、压缩或与 XML 互转，可以避免把带语法错误的数据继续传递下去。

用在线工具验证 JSON 的操作步骤

打开 JSON.cn 的在线解析/格式化页面。
把待验证的 JSON 文本粘贴到输入区。如果工具支持文件上传，也可以直接上传 .json 文件。
触发解析或格式化操作，观察输出区。
判断结果：
- 输出区正常显示出缩进后的结构，说明 JSON 合法。
- 出现红色报错或提示信息，说明不合法，需要按提示定位修复。

验证和格式化通常是同一次操作的两个结果：解析成功才会格式化，解析失败就只剩报错。所以看到格式化后的内容，本身就是验证通过的信号。

常见报错信息怎么读

不同解析器的措辞不完全一样，但指向的问题类型基本一致。下面这些是高频出现的：

报错关键词	大致含义	常见原因
Unexpected token	在某个位置遇到了不该出现的字符	多写、少写符号，或用了非法字符
Expected property name	期望出现属性名（键）	对象里键没加引号，或逗号位置不对
Unexpected end of input / EOF	输入意外结束	括号、引号没闭合，内容被截断
Expected ',' or '}'	期望逗号或右花括号	对象成员之间缺逗号，或多了内容
Unexpected non-whitespace character	出现多余的非空白字符	末尾多了分号、注释或额外文本

读报错时优先看它给出的行号和列号，直接跳到那个位置附近检查。很多解析器还会把出错字符前后的一小段内容一起显示出来，比只看文字描述更直观。

高频语法错误与修复方法

尾随逗号

{
  "name": "test",
  "age": 18,
}

最后一个成员后面多了逗号。JSON 不允许尾随逗号，删掉 18 后面的逗号即可。

用单引号代替双引号

{ 'name': 'test' }

JSON 的键和字符串值都必须用双引号。改成 { "name": "test" }。

键没有加引号

{ name: "test" }

对象里的键必须是带双引号的字符串，改成 { "name": "test" }。

写入了注释

{
  "name": "test" // 这是注释
}

标准 JSON 不支持 // 或 /* */ 注释。要么删掉注释，要么改用支持注释的格式（如 JSON5、JSONC），但那样就不再是标准 JSON。

字符串里有未转义的特殊字符

{ "path": "C:\Users\test" }

反斜杠在 JSON 字符串里是转义符，\U 不是合法转义序列。路径要写成 "C:\\Users\\test"。同理，字符串内部的换行、制表符、双引号都需要转义为 \n、\t、\"。

文件开头带 BOM

有些编辑器保存 UTF-8 文件时会加上字节顺序标记（BOM），它在文件开头，肉眼看不见，但会让解析器在第一个字符就报错。解决办法是用编辑器另存为「UTF-8 无 BOM」，或把开头那个不可见字符删掉。

括号或引号不配对

嵌套层级一多，很容易漏掉一个 } 或 ]。这类问题通常报 Unexpected end of input。建议借助编辑器的括号匹配高亮，或先把内容格式化再逐层核对。

定位错误的实用顺序

先看报错的行号、列号，跳到对应位置。
检查该位置前后的括号、引号、逗号是否配对和齐全。
如果报错位置看起来没问题，往前找——解析器往往是在读到下一个字符时才确认前面出了问题。
内容很长时，把 JSON 按顶层结构拆成几段分别验证，缩小范围。
确认没有注释、单引号、尾随逗号、BOM 这几类高频问题。

验证通过之后

验证只是第一步。确认合法后，可以继续在 JSON.cn 上做格式化（加缩进便于阅读）、压缩（去掉空白减小体积）、转义处理，或与 XML 相互转换。顺序上建议先验证再转换，因为带语法错误的 JSON 转成 XML 只会把问题一起带过去，排查起来更麻烦。

如果这段 JSON 来自接口返回或程序输出，验证不通过时还要回头检查生成端：是不是拼接字符串时漏了转义，是不是序列化库配置有误。工具只能告诉你「哪里不合法」，修不修、怎么修，取决于数据是怎么产生的。