JSON Schema 在生态中的位置：OpenAPI / AJV / Mock 联动

一、枢纽位置：一份契约，多方消费

把它想成中心节点：左边是「数据的形状从哪来」（真实报文 → 推断 Schema），右边是「形状被谁使用」（校验器、文档、代码、测试数据）。 没有统一 Schema 时，这些消费者各自维护一份定义，改结构就要满仓搜索替换。

• 校验消费者：AJV 等校验器、API 网关、表单校验。
• 契约消费者：OpenAPI 文档、接口平台、Mock Server。
• 代码消费者：Java POJO、TypeScript interface、Go struct 等。
• 数据消费者：示例 JSON、Mock 数据、测试夹具。

二、向上：成为 OpenAPI 的组件

OpenAPI 用 JSON Schema 描述请求与响应体，并集中在 components/schemas 里复用。因此一份写好的 JSON Schema，稍加包装即可被多个端点引用。典型做法是先有真实报文，用推断得到 Schema，再把它挪进 OpenAPI 的组件段。

复用手法与 $ref 与模块化 Schema 一脉相承：先在文档内用 definitions / $defs 抽取公共类型，再整体搬进 OpenAPI 的组件。

三、向下：AJV 校验与运行期防护

AJV 是 JS 生态最常用的 JSON Schema 校验器，输入即标准 Schema。推断得到的 draft-07 Schema 可直接用于 AJV， 在服务端入口或浏览器表单处做运行期校验。注意区分：Schema 能约束「形状」（类型、必填、枚举、format）， 但跨字段业务规则（如「结束时间不早于开始时间」）仍要在业务层补规则。站内推断生成的 required / enum / format 正好构成最常用的一层防护。

四、向右：从 Schema 生成代码与数据

契约稳定后，重复劳动可以自动化。以站内链路为例：

• 生成示例数据。Schema → JSON 示例 按 const / enum / default / format 生成符合约束的样例，用于联调与文档。
• 生成实体类。 把同一份 JSON 交给实体生成工具，产出 Java POJO、TypeScript interface、Go struct 等， 后端 DTO 与前端类型保持同源。
• 生成 Mock。智能 Mock 基于 JSON 或 Schema 生成带语义的假数据（姓名、邮箱、日期等），快速填充前端页面或测试夹具。

五、一条可复现的链路

把上面几步串起来，就是一条从真实报文到测试数据的完整流水线：

1. 粘贴后端返回的真实 JSON 到推断工具，得到 draft-07 Schema。
2. 按接口约定复核 required / enum / format（参考最佳实践一文）。
3. 用反推工具生成示例数据，自证 Schema 能产出合法结构。
4. 把 Schema 交给 AJV 做运行期校验、搬进 OpenAPI 做文档。
5. 用同一份 JSON 生成实体类与 Mock 数据，前后端各取所需。

每一步都在浏览器本地完成，环节之间通过复制或跳转衔接，数据不出设备。

六、常见误区

• 把 Schema 当万能校验。它管形状不管业务规则；跨字段依赖、时序约束必须在业务层实现。
• 契约与代码各写一份。结构变动时容易漏改，应让 Schema 作为单一真相并在 CI 里校验。
• format 当硬约束。多数校验器对 format 默认为提示级；要硬失败需显式开启或补正则。
• Mock 当真实数据。Mock 只为结构与语义逼真，不含真实业务取值，切勿用于生产或真实统计。