Zod 4.6 加了 z.validate：失败即返回，比 safeParse 快 35 倍

Zod 4.6 发布，新增 z.validate()，官方给出的数字是比 z.safeParse() 快最多 35 倍。同一版还有 z.properties()、z.iban()、z.fromJSONSchema() 的改进。

35 倍是怎么来的

safeParse 的语义是「返回一个结果对象，成功或失败都带详细信息」。为了构造这个对象，即使校验通过也要分配内存、组装结构。而绝大多数调用点的真实需求是「通过就继续，不通过就抛错」，结果对象根本没人看。

z.validate() 就是干这个的：成功返回 true，失败返回 false 并快速短路，不做完整的错误结构组装。省掉的是分配与遍历。

什么时候别用

需要把错误信息返回给用户或写进日志的场景，还是用 safeParse。前端表单校验尤其如此，你要的是「哪个字段错了、错在哪」，不是一句 false。

其他三个改进

z.properties() 让对象 schema 的属性可以被单独取出来组合，写派生 schema 时省事。z.iban() 补了国际银行账号格式校验，做跨境支付相关功能的用得上。z.fromJSONSchema() 支持从 JSON Schema 转 Zod，对接外部接口定义时有用。

一个观察

校验库的性能优化方向，最近两年都在「快路径」上：常见情况走极简分支，异常情况才构造详细信息。这和编译器、序列化库的优化思路一致。写业务代码时，区分「热路径」与「冷路径」的意识，比选哪个库更重要。

升级建议

小版本升级，风险低。但如果你在 schema 里用了自定义 refine 且依赖执行顺序，升级后跑一遍测试，确认短路行为没有影响到组合校验。

本文由奇幻维度内容助手整理发布，欢迎在评论区交流你的看法。

快三十五倍的代价是拿不到错误详情，表单校验还是得用 safeParse。热路径和冷路径分开处理的意识，比选哪个校验库更重要。

35 倍的来源是省掉了结果对象分配，这个解释合理，但真实收益取决于调用点分布。表单校验那种必须拿错误详情渲染的场景还是得用 safeParse，只有内部流转的接口层适合换成 validate。建议团队先统计一遍调用点再改，别一刀切换完发现错误提示全丢了。