Standard Schema 详解:无供应商锁定的灵活验证
你已经用 Zod 构建了应用。表单运行正常,API 验证请求,TypeScript 在编译时捕获类型不匹配。然后你的团队采用了一个只支持 Valibot 的新路由器。或者你想尝试 ArkType 以获得性能优势。突然间,你面临着重写——或者在不兼容的验证库之间维护适配器。
这就是 Standard Schema 解决的供应商锁定问题。它是一个小型接口,让验证库能够使用通用语言交流,因此使用它们的工具不需要关心你选择了哪个库。
核心要点
- Standard Schema 是一个 TypeScript 接口(不是验证库),它实现了 Zod、Valibot 和 ArkType 等验证库之间的互操作性。
- 它通过在模式生产者和消费者之间提供通用契约,将适配器问题从 N×M 关系减少到 N+M。
- 主流验证库和生态系统工具已经支持该规范,允许你在不重写表单、路由器或 API 处理程序的情况下切换验证器。
~standard属性暴露了一个 validate 方法、类型推断辅助工具和一个稳定的版本化契约。
Standard Schema 是什么(以及不是什么)
Standard Schema 不是另一个验证库。它不与 Zod、Valibot 或 ArkType 竞争。它也与 JSON Schema 或 schema.org 无关。
相反,它是一个 TypeScript 接口——大约 60 行类型代码——验证库可以实现它。当一个库在其模式上暴露 ~standard 属性时,任何理解 Standard Schema 的工具都可以验证数据,而无需知道是哪个库创建了该模式。
可以将其视为生产者-消费者契约。验证库是生产者:它们定义模式并实现接口。框架和工具是消费者:它们接受任何遵循契约的模式。
适配器泛滥问题
在 Standard Schema 之前,生态系统工具面临着不可能完成的维护负担。考虑一下数学:如果你有 6 个流行的验证库和 50 个需要验证的工具,你将面临 300 个潜在的适配器。每个适配器都需要维护、测试,并在任何一方更改时进行更新。
Zod、Valibot 和 ArkType 生态系统快速增长,但这种增长造成了碎片化。一个表单库可能原生支持 Zod,但需要社区适配器来支持其他所有库。这些适配器通常滞后、在更新时出现问题,或者根本不存在。
Standard Schema 将这种 N×M 关系减少到 N+M。库只需实现一次规范。工具只需消费一次。每个人都受益。
接口工作原理
该规范定义了三个基本要素:
一个 validate 方法,它接受未知输入并返回带有类型化值的成功结果或带有问题数组的失败结果。
类型推断辅助工具,让工具能够从任何兼容的模式中提取输入和输出类型,无论是哪个库创建的。
一个稳定的契约,版本化为 StandardSchemaV1,保证在没有主版本升级的情况下不会有破坏性更改。
~standard 属性故意使用波浪号前缀——它会排序到自动完成列表的底部,在正常开发过程中不会妨碍你。
Discover how at OpenReplay.com.
实践中的供应商中立验证
这种无锁定的灵活验证在整个技术栈中都有体现:
表单: TanStack Form 和 React Hook Form 接受 Standard Schema 验证器。编写一次验证逻辑,切换库时无需触碰表单代码。
路由: TanStack Router 使用任何兼容的模式验证路由参数和搜索参数。表单和路由中的 Standard Schema 意味着整个应用中的验证模式保持一致。
API: 像 tRPC 这样的工具验证请求体,而不耦合到特定的验证库。
配置: 像 envin 这样的工具在构建时使用你喜欢的任何验证器验证环境变量。
测试: 在测试中使用与验证生产数据相同的模式断言响应形状。
实现该规范的库
主流库已经支持 Standard Schema:
- Zod (v3.24.0+)
- Valibot (v1.0+)
- ArkType (v2.0+)
- Yup (v1.6.0+)
- Typia (v7.3.0+)
现在许多库都实现了该规范,有数十个工具在使用它。查看 Standard Schema 官方仓库 获取当前支持库的列表及其最低版本。
这对你的技术栈意味着什么
你可以从熟悉的 Zod 开始,切换到 Valibot 以获得更小的包体积,或采用 ArkType 进行类型级验证——所有这些都无需重写表单、路由器或 API 处理程序。
供应商中立的验证方法意味着你的架构决策不是永久性的。你可以根据库的优点来评估它们:API 设计、包大小、性能、错误消息。技术栈的其余部分保持稳定。
结论
Standard Schema 代表了一个成熟的生态系统。验证库之间不再是竞争导致工具格局碎片化,而是实现了互操作性。你对验证器的选择成为局部决策,而不是整个技术栈的承诺。
检查你当前的工具是否支持该规范。如果支持,你已经拥有了无锁定的灵活验证——你只需要使用它。
常见问题
不需要。Standard Schema 只是一个 TypeScript 接口规范。支持它的验证库会自动暴露 ~standard 属性。你像往常一样使用你选择的验证库,兼容的工具会自动检测该接口,无需额外的依赖。
切换库需要重写你的模式定义,因为每个库都有自己的 API。但是,表单库和路由器等消费工具将继续正常工作,无需更改,因为它们通过 Standard Schema 接口交互,而不是通过库特定的 API。
在工具的文档中查找 Standard Schema 的提及,通常在关于验证或类型安全的部分。你也可以检查工具是否接受带有 ~standard 属性的模式,或在其 TypeScript 类型中引用 StandardSchemaV1。
你可以创建一个薄包装器,在现有模式周围实现 ~standard 接口。这涉及暴露一个返回预期结果格式的 validate 方法。查看 Standard Schema 仓库获取实现示例和指导。
Gain Debugging Superpowers
Unleash the power of session replay to reproduce bugs, track slowdowns and uncover frustrations in your app. Get complete visibility into your frontend with OpenReplay — the most advanced open-source session replay tool for developers. Check our GitHub repo and join the thousands of developers in our community.