{
"$schema": "http://json-schema.org/draft-07/schema#",
"type": "object",
"properties": {
"id": {
"type": "integer"
},
"name": {
"type": "string"
},
"active": {
"type": "boolean"
},
"tags": {
"type": "array",
"items": {
"type": "string"
}
},
"profile": {
"type": "object",
"properties": {
"age": {
"type": "integer"
},
"city": {
"type": "string"
}
},
"required": [
"age",
"city"
]
}
},
"required": [
"id",
"name",
"active",
"tags",
"profile"
]
}关于 JSON 转 JSON Schema
JSON 转 JSON Schema 工具根据一段示例 JSON 自动推断字段类型、是否必填与嵌套结构，生成符合 Draft-07 或 2020-12 规范的 JSON Schema。它能显著降低手写 Schema 的成本，帮助你为接口请求体、配置文件或数据管道快速建立校验规则。推断结果可在右侧编辑微调，并复制粘贴到代码或表单校验库中。解析完全在浏览器本地进行，示例数据不会上传，适合处理含有业务字段定义的敏感样例。生成的 Schema 同时可作为文档，让前后端对数据结构达成共识，也便于接入 Ajv 等校验库做运行时数据质量把关。对于接口文档自动化，导出的 Schema 还能直接挂到 OpenAPI 里作为请求体定义复用；它既可作为运行时校验规则接入 Ajv 等库，也能当作前后端对数据结构的书面约定，减少因字段类型不一致导致的联调返工与潜在的线上数据质量问题。
从实例推导结构是一种「归纳」，得到的是「这份样本长这样」而不是「数据必须这样」。因此推断结果天然带有样本偏差：样本里恰好都出现的字段会被当成必填，偶然缺失的字段会被当成可选，而真正的约束（例如取值范围、字符串长度上限）在样本里根本看不出来。因此推断只能作为起点，随后必须由人补充意图。
数组是最容易推断失真的地方，因为单个样本往往只体现一种元素形态。同一数组在不同记录里可能是对象、字符串或数字，而推断工具通常取第一个元素或取交集，结果可能与实际不符。因此当结构里含数组时，应当用多份样本一起推断，或人工确认元素类型是否唯一，而不是直接接受推断结果。
格式类约束（日期、邮箱、标识符）无法从字面形式可靠地推导出来，这一层必须人工补上。同一串字符看起来像日期，也可能只是一个恰好符合日期形态的编号；反过来，一个字符串字段其实承载日期，但样本里全是难以识别的写法。因此格式约束应当由了解业务的人显式声明，而不是交给模式匹配去猜。
把重复出现的结构抽成可复用定义，是让结果可维护的关键一步。若同一形状在多个位置重复内联，任何一处调整都要同步修改多处，容易漏改；而抽成一个可被引用的定义后，修改集中在一点，且能保证各处一致。因此在生成之后应做一次结构梳理，把重复形状提取出来，即使这会让文件看起来复杂一些。
严格程度的选择需要与用途匹配，因为约束越严越容易拒绝合法数据。用于宽松校验时，只声明结构与类型即可，便于数据在演进中保持兼容；用于对外接口契约时，则需要把必填、枚举与格式一并固化，代价是每次扩展都要同步更新契约。因此同一份数据可能需要两个层次的描述，而不是只有一个最严格的版本。
最后，推断结果应当纳入版本管理并与真实数据保持对照。数据形态会随业务变化，而描述文件若长期不更新，会逐渐变成一份过时的说明，甚至比没有更糟，因为使用者会误以为它是准确的。因此把「样本变化后重新推断并人工复核」当作一个固定环节，比一次性生成后长期不管更有价值。
实现原理
从样例推断模式只能得到「样本里满足的约束」，而模式的用途恰恰是描述不变量。因此推断结果往往过于宽松（必填项被标成可选）或过于严格（把某次出现的取值写成枚举）。正确用法是把它当作起点，再人工收紧必填项、补齐取值范围与格式声明。
样例 {"id":1,"tags":["a"]}推断出 id 为整数、tags 为字符串数组，但**哪些字段必填无法从单一样本推断**——需要人工补齐 required使用方法
- 打开「JSON 转 JSON Schema」
- 选择源格式与目标格式
- 根据需要调整输出选项
- 点击「转换」按钮，结果实时显示
- 复制或导出结果
使用场景
- 接口契约校验 — 为 API 请求/响应生成 schema，用于运行时校验，拦截不合法的数据。
- 表单与配置校验 — 把配置样例转成 schema，配合 ajv 等库校验用户输入或配置文件。
- 生成 OpenAPI 片段 — 快速得到 schema 作为 OpenAPI/Swagger 文档中 components 的基础。
- 数据质量门禁 — 在数据管道中用 schema 做入口校验，保证下游消费的数据结构稳定。
- 团队结构对齐 — 用 schema 作为前后端共享的结构契约，减少沟通成本。
常见问题
生成的是哪个版本的 schema？
默认输出 JSON Schema Draft-07，兼容 ajv 等主流校验库。复制后可按需改成其它草案版本。
所有字段都会被标记 required 吗？
可以通过「标记 required」开关控制。开启时样例中出现的字段都会列入 required；如有可选字段，关闭后再手动调整更合适。
数组里类型不一致怎么处理？
当数组元素类型不同，工具会用 anyOf 列出各种可能的子 schema，尽量贴合真实数据。
整数和小数会区分吗？
会。整数推断为 integer，带小数的数字推断为 number，便于更精确的校验。
可以校验我的 JSON 吗？
本工具负责生成 schema。生成后你可以用 ajv、jsonschema 等库，或在线校验器对真实数据进行校验。
生成的 schema 太宽松、可接受太多值怎么办？
因为工具只从样例反推，样例里出现过 null 会把字段加成 anyOf 并含 null，空对象 {} 只能推断成 { } 等于什么都能装，样例越精简 schema 就越宽松。想收紧，可在右侧编辑器把 anyOf 里多余的 null 或类型分支删掉，给空对象补上 properties 和 required，并按业务加上 pattern 正则、minimum/maximum、maxLength 等约束，再拿真实样例跑一遍校验，看仍能通过哪些不该通过的值，逐步收敛到只放行实际业务允许的取值。
怎么给字段加枚举和 uniqueItems 这类约束？
生成后在右侧编辑器直接改对应字段的 schema 对象：给字符串加 pattern 或 minLength，给数字加 minimum/maximum，固定取值集合加 enum 数组，数组内容不重复加 uniqueItems:true。改完可复制进 ajv 等校验库，用一段真实数组各跑一遍，确认约束行为符合预期。约束越具体，运行时能拦下的脏数据越多，生成的 schema 也能当作接口契约与协作文档使用，减少联调阶段的类型不一致问题。
生成的 schema 里 required 字段是怎么定的？
按样本：该字段在所有对象样本里都出现就标记 required，缺失过就进 optional。样本越少判断越粗糙。严谨做法是给多个真实响应样本，或生成后手动审一遍 required 列表——schema 是接口契约，错一个字段下游都会踩坑。