应优先在 input 和 blur 事件监听实时校验，避免仅依赖 onsubmit；用 setcustomvalidity() 管理验证状态，动态字段需重绑事件并重置校验，正则校验慎用 ^$ 以免过早报错。
用 addEventListener 监听实时输入比 onsubmit 更早发现问题
用户还没点提交，字段就该提示错误——比如邮箱格式不对、密码太短。只靠表单提交时校验，体验差，也掩盖了真实输入问题。必须在 input、blur 甚至 keydown（针对数字/长度限制）上监听，但别滥用 keydown，它会拦截粘贴和中文输入法上屏。
实操建议：
-
input事件适合做格式类校验（邮箱、手机号正则），每次键入都触发，但注意防抖，否则高频触发影响性能 -
blur事件更适合必填、最小长度、确认密码一致性这类“离开字段时才需强反馈”的场景 - 避免给每个字段单独写一堆
addEventListener，用事件委托：监听form元素，通过event.target.name或event.target.dataset.validate分发校验逻辑
校验失败时，用 setCustomValidity() 而不是手动改 innerHTML
直接操作 DOM 写提示文字看似简单，但会绕过浏览器原生的表单验证机制，导致 checkValidity() 返回 true、reportValidity() 不生效、甚至影响 :valid/:invalid CSS 伪类。正确做法是调用 setCustomValidity() 设置错误消息，让浏览器统一管理状态。
关键细节：
- 校验通过时，必须调用
setCustomValidity('')（空字符串），否则字段会一直被标记为无效 -
setCustomValidity()不触发 UI 提示，要配合reportValidity()（手动触发）或依赖浏览器默认的提交拦截行为 - 若需自定义气泡位置或样式，只能覆盖默认 tooltip（需 CSS +
title属性），但兼容性有限；更稳妥的是在字段旁加<span class="error"></span>并同步更新其文本
动态添加的字段必须显式调用 addValidation() 初始化校验逻辑
用 document.createElement('input') 或模板字符串插入新字段后，它不会自动继承原有校验行为。DOM 节点是新的，事件监听器、setCustomValidity 状态、甚至 required 属性都得重新设置。
常见疏漏点：
- 忘记给新字段绑定
input和blur事件，导致“看起来有校验，实际没反应” - 复制已有字段 HTML 字符串时，没清除旧的
data-*校验配置或id，引发重复 ID 或逻辑错乱 - 新字段用了
type="email"但没设pattern，结果只触发浏览器基础邮箱格式检查，和业务规则不一致
正则校验慎用 ^ 和 $，尤其配合 input 事件时
比如邮箱校验写成 /^[^\s@]+@[^\s@]+\.[^\s@]+$/，用户刚输 a@b. 就会报错——因为 ^ 和 $ 要求“整个字符串”匹配，而输入是渐进的。这会让实时校验显得过于严苛。
更实用的写法：
- 去掉
^和$，改用/[^\s@]+@[^\s@]+\.[^\s@]+/，只要中间片段符合即可，避免过早拦截 - 对必填字段，优先用
required属性 +blur时检查非空，而不是靠正则判断“是否为空字符串” - 密码强度校验拆成多条独立规则（长度 ≥8、含大写字母、含数字），每条用独立正则，分别提示，别塞进一个超长正则里
setCustomValidity 或忽略动态节点初始化的操作，都会让后续的 form.checkValidity() 行为变得不可预测。最常被跳过的，其实是新字段插入后的 setCustomValidity('') 重置和事件重绑。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
