JSON 转 Schema 从样本 JSON 推断对应的 JSON Schema。工作原理是遍历 JSON 每个节点，把值的类型、嵌套结构、数组元素的共同骨架翻译成 Schema 约束。底层用 to-json-schema，纯浏览器运行。
string / number / integer / boolean / null）properties、required）uniform / first / all / tuple 策略合并）date-time / email / uri 等）需要在草稿基础上手动补：
description、titleenum、const，单样本看不出这是”取值集合”minimum / maximum、字符串长度限制patternanyOf / oneOf / allOf，需要多份对比样本才能推出来把本工具当作 Schema 的”骨架生成器”，拿到草稿后在编辑器里手动加 description、收紧 required、补 enum 和 pattern。然后用 JSON Schema 校验器 验证一组真实数据，迭代调整。
uniform（默认）假定数组里所有元素类型一致，用它们的合并结构生成 items；first 只看第一个元素，速度最快但不准；all 把所有元素的字段并集起来（适合字段可选不齐的列表）；tuple 把数组当成元组，每个位置独立推断类型（适合 [姓名, 年龄, 地址] 这种位置敏感的结构）。不确定就选 uniform。
打开时生成的 Schema 会把样本里出现过的全部字段写进 required。这在"样本代表完整契约"时合适；但一旦现实里某些字段是可选的，校验就会误报。建议流程：先打开勾选保留完整约束，然后手动从 required 数组里删掉可选字段。
不会。本工具只推断 type / required / 数组结构 / 对象属性 / format（如果开启）。它不会自动生成 minLength / maxLength / minimum / pattern 这些值约束——因为单个样本推不出合理的边界。想要严格 Schema，把输出作为草稿再手动加这些字段。
识别范围由底层 to-json-schema 的 strings.detectFormat 决定：date-time（ISO 8601）、date、time、email、uri、hostname、ipv4、ipv6。识别依据是字符串值是否匹配正则——只要样本里某个字段恰好是 ISO 日期，就会自动加上 format: date-time。如果这个识别是误判，关掉该选项即可。
对简单样本几乎没差别，主要影响 $schema 字段的 URL 和未来手动编辑时可用的关键字。2020-12 支持 prefixItems（元组）、$dynamicRef、独立 $defs 等；Draft 7 则用 items: [...] 表达元组、definitions 存共享片段。选对 Draft 可让下游工具（校验器、代码生成器）按正确语法解析。
勾上后会在 Schema 根部加 examples: [原始样本]，这样 Schema 既是契约也带一份"长这样"的示例。适合写接口文档、发布到 schemaStore；不适合作为线上 API 契约（暴露真实数据）。