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、title）enum）、常量（const）——单样本看不出这是”取值集合”minimum / maximum）、字符串长度限制pattern）anyOf / 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 契约（暴露真实数据）。