Yup 和 Zod 是纯 JavaScript 运行时验证库，不直接介入 HTML 原生表单 submit 事件或 DOM 属性校验；必须手动监听 submit、阻止默认行为、调用 validate()/safeParse() 并处理错误映射到 UI，且需提前定义 schema、将 FormData 转为对象、注意类型转换与空值处理。
Yup 和 Zod 本身不直接介入 HTML 原生表单的 submit 事件或 DOM 属性校验，它们是纯 JavaScript 运行时验证库，必须配合 JS 逻辑调用（如 schema.validate() 或 schema.safeParse()）才能生效。不能像 required 或 pattern 那样写在 HTML 标签里“声明式生效”。
Yup 与原生表单 submit 事件怎么联动
你需要手动监听 submit，阻止默认提交，再调用 Yup 验证；验证失败时收集错误并更新 UI（比如插入 <span class="error"></span>）。
- Yup schema 必须提前定义好，不能在事件回调里重复创建（否则影响性能）
-
schema.validate()是异步的（即使全是同步规则，它也返回 Promise），要用await或.then()处理 - 错误对象的
errors字段是字符串数组，不是按字段组织的——想映射到具体 input，得用inner或path字段解析 - 示例片段：
const form = document.querySelector('form'); const schema = yup.object({ email: yup.string().email().required(), }); form.addEventListener('submit', async (e) => { e.preventDefault(); try { await schema.validate(Object.fromEntries(new FormData(form)), { abortEarly: false }); form.submit(); // 验证通过才真提交 } catch (err) { // err.inner 是每个字段的 ValidationError 数组 err.inner.forEach(({ path, message }) => { const el = form.querySelector(`[name="${path}"]`); if (el) el.setCustomValidity(message); }); form.reportValidity(); } });
Zod 的 safeParse 更适合前端表单容错处理
zod 推荐用 schema.safeParse() 而非 parseAsync()，因为前者不抛异常，返回 { success: boolean, data?: T, error?: ZodError }，更适合表单这种“可能出错”的交互场景。
-
ZodError的format()方法可生成嵌套结构化的错误对象，方便按字段渲染提示 - 注意：Zod 默认不处理
FormData，需先转成普通对象（Object.fromEntries(new FormData(form))），且数字/布尔等类型会是字符串，必要时用z.coerce（如z.coerce.number()） - 如果表单字段有空字符串但 schema 要求非空，Zod 默认不会自动 trim，得加
.trim()或用z.preprocess()
为什么不能把 Yup/Zod 规则写进 HTML 属性里
HTML 的 pattern、minlength 等属性只支持极简规则，而 Yup/Zod 的能力（如跨字段依赖 .oneOf([yup.ref('password')])、异步校验 .test()、嵌套对象结构校验）完全超出 HTML 属性表达能力范围。
立即学习“前端免费学习笔记（深入）”；
- 强行“模拟”会导致严重割裂：比如你用
pattern写邮箱正则，又用 Yup 再写一遍，维护两套逻辑极易不一致 - 浏览器原生校验的错误提示样式和时机（如 focusout 后才触发）无法被 Yup/Zod 控制
- 真正“声明式”是指代码层面的 schema 定义（如
z.object({ name: z.string().min(2) })），不是 HTML 标签里的属性声明
最易被忽略的一点：Yup/Zod 验证的是数据结构，不是 DOM 状态。如果你没手动从 FormData 或 input.value 提取值，它们根本不知道用户填了什么——这和 HTML5 原生校验的触发机制有本质区别。
