Zod用户苦等3年：60倍提速插件终于不用改代码了

一个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倍是怎么测出来的，以及谁在和谁比

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吗？还是说，这种"看不见的黑魔法"反而让人不安？