打开网易新闻 查看精彩图片

一个Vite插件,让Zod(JavaScript 运行时类型校验库)的验证速度提升60倍,而且你一行业务代码都不用动。这事听起来像那种"骗star的玩具项目",但作者Colin McDonnell(Zod核心维护者之一)真的做出来了。

3个月前,Zod AOT(Ahead-of-Time,预编译)还需要你手动包裹每个schema;现在,autoDiscover模式让构建工具自己去找、自己去编译。

这解决了类型校验领域的老大难问题:要么用Zod写起来爽但跑得慢,要么用AJV(Another JSON Schema Validator,另一款JSON校验器)跑得快但写起来像写配置文件。现在有人试图两头都要。

从"改代码"到"零侵入",中间隔了一次用户 rebellion

Zod AOT的第一版发布时,Colin收到了一条压倒性的反馈:"我不想改我的代码。"

这很合理。Zod的吸引力就在于它的API设计——链式调用、类型推断、运行时校验三合一。如果为了性能要包裹一层compile(),相当于承认这套设计在工程上走不通。

Colin的解决方案是把包袱甩给构建工具。Vite插件在构建时做四件事:扫描文件→找Zod运行时导入→检查导出对象是否带_zod.def标记→编译替换。

关键在第三步。Zod schema内部有个_zod属性,里面存着def(定义对象)。这不是公开API,但足够稳定。插件用jiti(一个Node.js 运行时加载器)在构建时执行模块,拿到真实的schema对象,然后塞进编译管道。

整个过程中,你的src/schemas.ts保持原样,连zod-aot的import都不会出现。

这有点像Babel早期的"语法糖转译"——开发者写ES6,工具转成ES5。区别在于,这里转译的不是语法,是运行时的行为。

打开网易新闻 查看精彩图片

60倍是怎么测出来的,以及谁在和谁比

60倍是怎么测出来的,以及谁在和谁比

Colin更新了benchmark,加入了两个新对手:Typia(另一个追求性能的TypeScript 校验库)和AJV。

测试场景是嵌套对象验证,结果分三档:

Zod原生:基准线,1x。优雅,但每个校验都要遍历schema结构。

Typia:约20-40x。用TypeScript 编译器生成校验代码,但需要你写特殊语法。

AJV + JSON Schema:50-100x。预编译模式,但你要先写JSON Schema定义。

Zod AOT的目标区间是40-60x。Colin还加了个"Fast Path"两阶段验证器——先跑一遍轻量检查,通不过再回退完整校验。这对"大部分输入其实是对的"场景很有效。

数字背后有个工程权衡:Zod AOT的编译产物是IIFE(Immediately Invoked Function Expression,立即执行函数表达式)包裹的校验函数,没有依赖,可以直接内联。这意味着bundle体积会涨一点,但运行时零开销。

自动发现模式的边界,以及它没解决的事

自动发现模式的边界,以及它没解决的事

autoDiscover不是万能的。它只处理运行时导入的Zod——import { z } from "zod"会触发,import type { z } from "zod"会被跳过。这是刻意的设计,避免把类型定义文件拖进编译。

打开网易新闻 查看精彩图片

动态生成的schema也抓不到。比如你在函数里return z.object({...}),这个schema是运行时才存在的,构建时扫描不到。Colin的建议是:这类场景继续用原生Zod,或者手动标记。

还有个隐藏成本:构建时间。大型项目里扫描全量文件不是免费的,虽然Colin说"大部分文件会被快速跳过",但具体慢多少,取决于你的项目结构。

CLI诊断工具是这次同步发布的。跑npx zod-aot diagnose,它会告诉你哪些schema被编译了、哪些被跳过、为什么跳过。这对调试"为什么我的schema没提速"很有用。

类型校验库的战争,正在从"功能"转向"工程体验"

类型校验库的战争,正在从"功能"转向"工程体验"

Typia的作者之前写过一篇长文,论证"Zod的设计哲学注定慢"。他的方案是拥抱TypeScript 编译器,把类型直接变成校验代码。代价是:你的代码要写成typia.createAssert(),类型和校验代码在两个地方维护。

AJV的路线更极端:完全抛弃运行时定义,用JSON Schema描述一切。性能最好,但开发体验像回到XML时代。

Zod AOT的赌注是:开发者已经用Zod写了大量代码,迁移成本是真实存在的。如果能在不改动这些代码的前提下榨出性能,比说服大家重写更有价值。

这有点像Vite对Webpack的胜利——不是功能更多,是假设你已经有一个庞大的JS生态,然后让你无痛迁移。

目前Zod AOT还是实验性项目,版本号0.x。Colin在GitHub discussion里回复用户提问时说,稳定版的目标是让"autoDiscover成为默认推荐,compile()留给边缘场景"。

如果你的项目已经在用Zod,会愿意让构建工具偷偷改写你的schema吗?还是说,这种"看不见的黑魔法"反而让人不安?