从例子出发
对象、数组、字符串、数字会映射到对应 type。嵌套对象会尽量展开 properties。
空数组缺少元素样本时，items 类型可能不准，请补一条真实元素再推断。
JSON Schema 校验
本地处理 也可通过 #data={"name":"Ada"} 或 #url=... 灌入数据，读完即从地址栏清除。
使用说明
根据一份示例 JSON 推断 JSON Schema。适合先有真实响应、再补接口文档或给校验器当起点。推断结果请人工核对必填项和枚举——工具只能看到「这份例子里有什么」，看不到「业务上必须有什么」。
当草稿用
自动推断无法知道「这个字段是否必填」，需要你改 required。可选字段、枚举、format（email、uri）也需要人工补。
生成后交给 ajv 等工具在 CI 里跑，比只靠口头约定稳。
本地生成
示例数据不会上传。用生产样例时仍建议先脱敏。
输出含 $schema 声明，方便其它工具识别版本。
示例
{
"id": 1001,
"name": "Ada",
"active": true
}{
"type": "object",
"properties": {
"id": { "type": "number" },
"name": { "type": "string" },
"active": { "type": "boolean" }
}
}能用来校验另一份 JSON 吗？
本页侧重由示例生成 Schema。把生成结果交给你们的后端或 CI 里的 ajv 等工具再做校验。
嵌套和数组呢？
会尽量往下推断。空数组缺少元素样本时，item 类型可能不准。
和 GraphQL 页怎么选？
REST / JSON 文档用 Schema；GraphQL 服务用类型推断页。
会标 format: email 吗？
以类型推断为主。邮箱等格式请对照业务补进 Schema。
推荐工作流
- 准备一份「字段尽量齐全」的成功响应样例。
- 生成 Schema，检查 type 和 properties 是否合理。
- 手工补 required、enum、additionalProperties 等约束。
- 放到 Mock / CI 里校验后续响应，和 Diff 一起做版本审查。
一份例子推不出完整契约。最好用多条样例交叉核对，再收紧 Schema。