JSON 进阶四件套：Schema 推断、校验、Patch 与 Pointer

接口返回一大坨嵌套 JSON，写文档、写断言、写增量更新都要跟它打交道。四个配套规范各自解决一个环节：Schema 描述「长什么样」，校验判断「合不合规」，Patch 表达「改了哪里」，Pointer 定位「具体哪个值」。把这四个工具串起来用，JSON 相关的杂活基本就齐了。

一、Schema 推断：从样例倒推结构

手写 JSON Schema 很枯燥。把一段真实响应粘进推断工具，它会自动识别字段类型、必填项、数组元素结构与嵌套对象，生成 draft-07 Schema。要点：

• 样例要「典型」：尽量给字段齐全、有值的一条，空值太多会让推断偏松；
• 推断结果是起点：把 optional 字段、枚举值、数值范围、正则 pattern 再手工补上，才是能进接口文档的正式 Schema；
• 数组会看元素结构，混合类型数组需要人工收紧。

二、Schema 校验：让错误带上路径

有了 Schema，就能用校验工具逐字段检查数据，支持 type、required、enum、minimum、pattern 等常用关键字。它最大的价值不是「通过/不通过」，而是列出所有错误路径——比如 /data/items/2/price 类型不符，直接定位到数组第 3 个元素，排查接口契约问题不用肉眼扫。

建议把它用在三个地方：联调时验后端返回、上线前验配置数据、写自动化测试前先确认样例有效。

三、JSON Patch 与 Pointer：增量更新的两条腿

Patch 生成对比修改前后的两份 JSON，自动产出 add / remove / replace 操作序列，支持嵌套对象与数组差异，直接复制给增量更新接口用。比整份重传省带宽，也更容易做审计记录。

Pointer 查询按路径取值，支持数组下标、~0（转义 ~）与 ~1（转义 /），还能一键列出全部叶子路径——写接口断言、找配置项位置时特别顺手。

四、常见问题

问：推断出的 Schema 能直接用于生产校验吗？
不建议。单条样例推断不出「哪些字段必填」「取值有哪些枚举」「字符串长度限制」，这些业务约束要手工补。先推断再收紧，是标准做法。

问：Patch 里数组用下标会不会错位？
会。RFC 6902 的 add/remove 会改变后续下标，生成操作序列时工具按最长公共子序列处理，但业务上仍建议在数组元素有稳定 id 的场景使用，避免并发修改撞车。

问：这些工具会上传我的接口数据吗？
不会，四个工具都在浏览器本地计算，粘贴的 JSON 不出本机，处理含真实字段的响应也放心。

五、一条串联起来的工作流

1. 拿到真实响应 → 推断 Schema → 人工补齐约束，沉淀为接口文档；
2. 后续每次联调 → 用 Schema 校验返回，错误路径直接定位字段；
3. 写断言或找配置 → 用 Pointer 列出叶子路径，挑出要断言的那几条；
4. 做增量同步 → 对比新旧两份 JSON 生成 Patch，只传变化的部分。

四个规范各自都不复杂，但组合起来正好覆盖「描述—验证—定位—更新」的完整链路。收藏这一组，下次面对深层嵌套 JSON 就不用一层层手动展开了。