2026-06-04dev

JSON Formatter and Validator：在线校验 JSON 时该看什么

使用 JSON Formatter and Validator 在线校验 JSON：区分语法合法、结构可读和业务 schema 通过三件事，排查 trailing comma、非法转义、双重序列化、Unicode、数字精度、JWT/Base64 包装和生产 payload 脱敏边界。

在线 JSON 校验工具最容易被误用成“把一段文本变漂亮”。真正排查 API 问题时，你需要的是三个结论：这段文本是否是合法 JSON；格式化后的结构是否和你以为的一样；它是否满足应用或接口 schema。前两个问题可以用 JSON Formatter 快速确认，第三个问题必须结合业务规则、接口文档或服务端校验结果。

这篇文章聚焦在线 validator 的判断边界。它不假设你正在写新 JSON，而是假设你拿到一段来自浏览器、日志、webhook、SDK、低代码平台或第三方后台的 payload，需要判断它到底错在哪里。

“合法 JSON”不是“正确数据”

JSON validator 的第一层职责是语法。它能告诉你文本是否符合 JSON 语法规则：对象 key 用双引号，字符串用双引号，不能有注释，不能有 trailing comma，数字不能写成 NaN 或 Infinity，字符串里的控制字符必须转义。

但合法 JSON 可能仍然是错误数据。例如：

{
  "userId": "42",
  "quantity": "3",
  "status": "PAIED"
}

这段 JSON 语法上完全合法，却可能被 API 拒绝：userId 也许必须是数字，quantity 也许不能是字符串，status 也许拼错了枚举值。validator 不知道你的业务规则。它只能证明“解析器能读懂”，不能证明“服务端会接受”。

因此排查时要把结论分层写清楚：

语法层：是否能被 JSON parser 解析；
结构层：字段、嵌套、数组、类型是否符合预期；
业务层：schema、枚举、权限、状态机、签名和时间是否通过。

当你向同事描述问题时，说“JSON 是合法的，但 schema 不通过”比说“JSON 没问题”更准确。

校验失败时，先处理第一个断点

JSON 解析器通常会报告它停止的位置，而不是完整修复方案。第一个错误最重要，因为它可能引发一串后续假错误。比如上一行少了一个引号，下一行的冒号、逗号、花括号都可能被解析器误读。

常见断点可以这样判断：

报错附近现象	优先检查
`Unexpected token }` 或 `]`	前一项后是否多了逗号，括号是否提前关闭
字符串中间报错	是否有未转义引号、真实换行或反斜杠
key 附近报错	key 是否用了单引号或没加引号
数字附近报错	是否有 `01`、`NaN`、`Infinity`、尾随小数点
文件末尾报错	是否缺右括号、右方括号或字符串结束引号

不要一边看报错一边凭感觉批量替换。先修一个点，重新校验，再继续。这样才能确认每次改动解决了哪个问题。

从 JavaScript 对象复制来的内容经常不是 JSON

很多“JSON 校验失败”其实是复制来源错了。下面这些写法在 JavaScript 里常见，但不是标准 JSON：

{
  id: 123,
  name: 'demo',
  active: true,
  tags: ['api', 'test'],
}

问题包括：key 没有双引号、字符串使用单引号、最后一项带 trailing comma。把这段内容发给 JSON API，严格解析器会拒绝。正确做法不是让 formatter “自动猜”，而是回到生产代码或文档，确认发送出去的到底是序列化后的 JSON，还是开发者手写的对象字面量。

如果 payload 来自环境变量、CMS 字段或配置面板，还要注意它可能被外层字符串包住。例如整个 JSON 可能变成：

"{\"id\":123,\"name\":\"demo\"}"

这在 JSON 语法上是一个字符串，不是对象。validator 可以解析它，但应用如果期待对象，仍然会失败。看到格式化结果最外层是一对引号时，要优先怀疑双重序列化。

数字、时间和 Unicode 要单独看

有些 payload 语法合法，结构也看似正确，却在运行时出问题，原因常常藏在值的边界。

大整数 ID 是典型例子。JavaScript 对超出安全整数范围的数字会有精度风险。如果订单号、用户 ID、雪花 ID 或数据库主键很长，最好按字符串传输，而不是让前端把它当数字计算。validator 不会替你判断业务 ID 是否应该是字符串。

时间字段也类似。"2026-06-10"、"2026-06-10T08:00:00Z"、Unix 秒、Unix 毫秒都是合法 JSON 值，但服务端解释完全不同。排查日期问题时，不要只看字段存在，还要确认单位、时区和格式。

Unicode 问题通常出现在重复转义或编码转换之后。正常 JSON 可以直接包含中文，也可以用 中 这类转义表示。真正可疑的是破碎字符、问号替代符、异常反斜杠，或者本应是文本的字段被二次序列化成一长串转义内容。此时应检查生产链路，而不是只在工具里手动改到能看懂。

JWT、Base64 和 JSON 字符串不要混成一类

不是所有看起来像长字符串的内容都应该丢进 JSON validator。JWT、Base64、签名、加密结果、压缩数据都可能出现在 JSON 字段里，但它们不是同一件事。

JWT 应使用 JWT Decoder 查看 header 和 payload。JWT 的两个可读片段是 Base64URL 编码的 JSON，但整段 token 有三个点号分隔的部分；把整段 token 当普通 JSON 或普通 Base64 处理，常常得到错误结论。

Base64 包装的 JSON 可以先用 Base64 Encoder 解码，再把解码结果放进 validator。但前提是你已经确认该字段确实是 Base64。签名和加密值即使能“看起来像编码”，也不应该尝试格式化成 JSON。

转义 JSON 字符串则是第三类问题。它本身可以是合法字符串，但不是对象。判断标准是：生产方是否明确约定这个字段保存 JSON 文本。如果没有，这往往是序列化次数错误。

在线校验前的脱敏边界

在线工具适合快速排查，但生产 payload 往往包含不该暴露的内容。脱敏不是简单删除所有值，而是创建一个仍能代表问题的样例。

安全处理建议：

access token、refresh token、session id、签名、密钥一律替换；
邮箱、手机号、客户名、地址、订单号替换成示例值；
内部 URL、租户名、项目名按需要模糊化；
保留字段类型，例如字符串仍替换成字符串，数字仍替换成数字；
如果问题与长度、数组数量、null、缺失字段有关，脱敏时保留这些特征。

错误脱敏会制造新问题。比如把 "id": "123456789012345678" 改成 "id": 1，你就同时改变了类型、长度和精度风险。这样的样例无法说明原问题。

一个实用的在线校验顺序

拿到一段可疑 JSON 时，可以按下面顺序判断：

记录来源：Network、日志、webhook、配置、数据库还是人工复制；
保留原文，不在原文上直接修改；
放入 validator，确认语法是否成立；
如果失败，只处理第一个报错位置；
如果成功，看最外层是 object、array、string 还是其他值；
检查关键字段类型、null、缺失字段、数组长度和嵌套层级；
对长字符串判断外层格式：JWT、Base64、转义 JSON、签名或加密；
脱敏后整理最小复现样例；
最后再用接口 schema 或服务端日志验证业务原因。

这个顺序的重点是避免跳步。先证明文本能解析，再证明结构正确，最后才谈业务。

FAQ

Validator 显示合法，为什么后端仍然报 schema error？

因为 JSON 语法和业务 schema 是两层规则。validator 不知道你的必填字段、枚举、类型约束、权限状态、时间单位或签名规则。

最外层是字符串也算合法 JSON 吗？

算。JSON 顶层可以是字符串、数字、对象、数组等值。但如果 API 期待对象，而你传的是一个包含 JSON 文本的字符串，业务上仍然是错的。

可以相信自动修复后的 JSON 吗？

自动修复只能当线索。它可能补出一个语法合法但不符合事实的 payload。排查生产问题时，应保留原始文本，并标注哪些地方是手动修正。

解码 Base64 后还是乱码怎么办？

先确认它确实是 Base64，并确认字符集。如果结果像二进制、压缩包、加密块或签名，不要继续当 JSON 处理。

返回教程列表