JSON 转 JSON Schema:转换差异、边界与常见坑

JSON 转 JSON Schema 在线转换:从样本数据反向推导 Schema,生成 properties、required 与类型声明,数组会合并元素类型,可输出 draft-07 或 2020-12 版本。适合把现有接口响应变成校验规则,用于自动化测试、表单校验与文档约束。

从一份真实 JSON 样本反推出 JSON Schema,用来做接口契约校验、文档生成与前端类型推导。生成的是"结构约束"而不是"业务规则"——required 列表、枚举范围、字段间依赖这些业务语义必须人工补,工具只能告诉你"样本里长什么样"。

两种格式的差异对照

维度JSON 样本JSON Schema
表达内容具体的值(张三、18 岁)约束规则(必须是 string、最小长度 1)
必需性字段出现或不出现required 数组显式声明,可校验缺失
类型约束值本身的类型type 关键字,可组合 anyOf/oneOf
取值范围样本里恰好取到的值enum / minimum / pattern 等约束可手写
可复用性一份样本一份结构可被多个接口引用($ref、$defs)
文档能力需要人读数据猜含义description 字段可直接作为文档
校验时机运行时才发现不符请求入口即可拦截,返回结构化错误
样本依赖不存在强依赖:样本不全会生成错误约束

边界条件

  • 只有一个样本时,缺失字段会被误判为 optional,导致线上真出现该字段时校验不通过(漏约束的反面是过约束)。
  • 样本中的 null 会让类型推断变成 ["string","null"],如果实际接口不允许 null,需要手工删掉。
  • 空数组、空对象无法推断元素结构,生成的 schema 过于宽松(additionalProperties 全开),校验形同虚设。
  • 深层嵌套超过 4–5 层后,$defs 与 $ref 的拆分策略因工具而异,跨工具复用 schema 时需要核对引用路径。

常见坑

  • 把生成的 schema 直接当成接口契约上线,required 漏掉真正必填的字段,坏数据照样入库。
  • 用生产环境的敏感样本生成 schema,样本本身被带进文档或提交到代码库。
  • 异构数组只按第一个元素定型,第二个元素类型不同就整批校验失败。
  • 数字字段被推断为 integer,接口一旦返回 18.5 立刻全部不通过。

相关工具

常见问题

生成的 required 列表可信吗?

不完全可信。工具按"该字段在样本里是否都出现"来推断 required:样本多、覆盖全则准确;只有一个样本时,碰巧缺失的字段会被误判为可选。严谨用法是喂 5–10 个真实响应(含异常返回),再人工过一遍 required——它是接口契约里最容易被写错的一行。

数组元素的类型是怎么定的?

取数组第一个元素的类型。若数组为空,只能得到泛化的空 schema;若元素异构(有时是对象有时是字符串),推断结果只符合第一个元素,后续校验会把合法数据判为非法。异构数组需要手工改成 anyOf。