JSON Schema 验证器

示例：订单回调里的 19 位订单号

雪花算法生成的订单号常有 19 位，超出 JavaScript 数字能精确表示的范围（2^53）。下面这份回调数据把订单号写成了数字：

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "required": ["orderId", "mobile", "amount", "status"],
  "properties": {
    "orderId": { "type": "integer", "maximum": 9007199254740991 },
    "mobile": { "type": "string", "pattern": "^1[3-9][0-9]{9}$" },
    "amount": { "type": "integer", "minimum": 1 },
    "status": { "enum": ["待支付", "已支付", "已退款"] },
    "receiver": { "type": "string", "minLength": 2, "maxLength": 10 }
  }
}

{
  "orderId": 1842390023517843457,
  "mobile": "1381234567",
  "amount": 19.9,
  "status": "已发货",
  "receiver": "张"
}

无法确定（Draft 2020-12）：输入涉及校验器无法可靠检查的情况，因此不给出有效或无效的结论。原因见下方。
无法确定，原因：
- 数据中有 JavaScript 无法精确表示的数字：1842390023517843457 被读成 1842390023517843500，而 Schema 会比较数字。
* 数据的 /orderId 中的数字 1842390023517843457（第 2 行）无法在 JavaScript 中精确表示，被读成 1842390023517843500。

数据里写的是 1842390023517843457，浏览器读到的却是 1842390023517843500，而 Schema 要比较这个数字。按改写后的数去判定，结论可能是错的：不加 maximum 时这个字段会“通过”，但通过的是另一个数。所以工具不给出有效或无效的结论，只显示“无法确定”和原因，其他字段的错误也先不列出。Python jsonschema 用任意精度整数，会按原值判断；浏览器里的校验器都做不到。

改法是让订单号在接口里按字符串传输，Schema 用 pattern 约束位数。改完后其余四处问题就显示出来了：

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "required": ["orderId", "mobile", "amount", "status"],
  "properties": {
    "orderId": { "type": "string", "pattern": "^[0-9]{19}$" },
    "mobile": { "type": "string", "pattern": "^1[3-9][0-9]{9}$" },
    "amount": { "type": "integer", "minimum": 1 },
    "status": { "enum": ["待支付", "已支付", "已退款"] },
    "receiver": { "type": "string", "minLength": 2, "maxLength": 10 }
  }
}

{
  "orderId": "1842390023517843457",
  "mobile": "1381234567",
  "amount": 19.9,
  "status": "已发货",
  "receiver": "张"
}

4 个错误，涉及 4 个位置（Draft 2020-12）。
/mobile (第 3 行第 13 列): 不匹配正则 ^1[3-9][0-9]{9}$  Schema #/properties/mobile/pattern
/amount (第 4 行第 13 列): 必须是 integer，实际是 number  Schema #/properties/amount/type
/status (第 5 行第 13 列): 必须是 "待支付", "已支付", "已退款" 之一  Schema #/properties/status/enum
/receiver (第 6 行第 15 列): 至少 2 个字符，实际 1 个  Schema #/properties/receiver/minLength

amount 以分为单位时应是整数，19.9 被 "type": "integer" 拦下；minLength 按 Unicode 字符计数，“张”是 1 个字符。

示例：输入法打出的全角标点

在中文输入法下手写 JSON，最容易混进全角冒号、全角逗号和中文引号。JSON.parse 只会说“Unexpected token”，本工具会指出是哪个字符、在第几行第几列：

{ "type": "object", "properties": { "city": { "type": "string" } } }

{
  "name": "张三",
  "city": “上海”
}

数据不是有效的 JSON、YAML 或 JSON Lines。
第 3 行第 11 列："“" 是中文引号，JSON 要用英文双引号（"）

点击这条错误，数据框会选中出错的字符。全角冒号 ： 和全角空格同样会单独提示。

示例：YAML 配置文件

配置文件常用 YAML。下面的 Schema 和数据都是 YAML，Schema 用 unevaluatedProperties: false 拦下拼错的键：

$schema: https://json-schema.org/draft/2020-12/schema
type: object
required: [appName, port]
properties:
  appName: { type: string }
  port: { type: integer, minimum: 1, maximum: 65535 }
  launchDate: { type: string, format: date }
unevaluatedProperties: false

appName: 订单服务
port: "8080"
launchDate: 2026-10-01
prot: 8081

2 个错误，涉及 2 个位置（Draft 2020-12）。
/port: 必须是 integer，实际是 string  Schema #/properties/port/type
（根）: 不允许属性 "prot"（unevaluatedProperties）  Schema #/unevaluatedProperties
* Schema 按 YAML 读取（1 个文档）。日期和 yes / no 保持为字符串（YAML 1.2 core schema）。
* 数据按 YAML 读取（1 个文档）。日期和 yes / no 保持为字符串（YAML 1.2 core schema）。

YAML 按 1.2 core schema 读取，所以 2026-10-01 仍是字符串，能通过 format: date；加了引号的 "8080" 是字符串，不是整数。YAML 的错误只显示路径，不显示行号。

错误怎么归并

Ajv 会把 oneOf / anyOf 每个失败分支的错误全部列出。比如“银行卡或银行账户”两种支付方式，银行卡号写错时，Ajv 会给出 5 条错误，其中 3 条来自根本不相关的账户分支。本工具只在 /payment 显示 1 条错误，并展开 最接近的分支（错误最少的分支，const 判别字段不符的分支排在后面），其他分支折叠起来；分支写成 $ref 时同样有效。if / then 不满足时，直接显示 then 里的错误，并标注“经由 then”。

和其他在线工具的对比

2026-10-02 用同一组输入测试了 cn.bing.com 搜索“json schema 校验”排名第一的在线工具大全（lddgo.net），默认规范为 Draft-07：

两者都在浏览器里运行，测试中都没有发出包含数据的请求。lddgo.net 把错误显示为 Ajv 的原始 JSON 对象。

限制

• 校验器是 Ajv 8.18（ajv-formats 3.0.1、ajv-draft-04 1.0.0）。在官方 JSON Schema Test Suite 的必选用例中，draft-07 有 927/929 项、2020-12 有 1,210/1,301 项给出预期结果，其余（2 项、91 项）显示“无法确定”，没有给出错误结论的用例。Ajv 已知会判错的情况都按“无法确定”处理：$dynamicRef、首个目标没有 $recursiveAnchor 的 $recursiveRef、相对引用加嵌套 $id（Ajv 栈溢出）、unevaluatedItems / unevaluatedProperties 与 contains、缺 then 或 else 的 if、anyOf / oneOf 分支内的 items 组合、改了 $vocabulary 的元 Schema，以及数据中也有的 __proto__ 属性。判定只看 Schema 和数据的结构，所以 Ajv 本来答对的部分用例（例如所有用到 $dynamicRef 的）也在其中。
• $ref 指向的网址不会被下载。
• JavaScript 无法精确表示的数字（9007199254740993、1.0000000000000001、1e400 等）会提示并写出行号；Schema 要比较数字时，该文档显示“无法确定”。这类数字出现在 Schema 或 YAML 数据里时一律“无法确定”。0.1、1.0 这类能精确读出的数字照常判定。multipleOf 按十进制数值判断：19.99 是 0.01 的倍数，0.3 是 0.1 的倍数（像 Ajv 那样用浮点数相除会判为不是）。重复的键只保留最后一个值，也会提示。
• 超过 1 MB 的输入需要点“验证”；超过 20 MB 的文件不读取。
• pattern 按 ECMA-262 正则（u 标志）执行，\d 只匹配半角数字 0–9。

需要从样例数据生成 Schema，可以用 JSON 转 JSON Schema；只检查 YAML 语法，用 YAML 语法验证器；校验整份接口文档，用 OpenAPI 验证器。