checkValidity()可主动触发浏览器原生验证并返回布尔值，配合reportValidity()显示默认提示；invalid事件不可阻止但可用于前置处理；setCustomValidity(”)是重置验证状态的必要操作。
用 checkValidity() 快速触发原生验证
浏览器自带的表单验证机制在大多数场景下足够用，关键是要主动触发它，而不是只依赖提交时的默认行为。checkValidity() 会立即运行所有 required、type="email"、pattern 等约束，并返回 true 或 false。
常见错误是只监听 submit 事件却没调用 Event.preventDefault()，导致页面刷新掩盖了验证失败；或者手动写正则却忽略浏览器已支持的语义化校验。
- 对单个
调用input.checkValidity()，它还会触发invalid事件（可用于自定义提示） - 对整个
form.checkValidity()，返回false表示至少一个字段不通过 - 配合
reportValidity()可强制显示浏览器默认气泡提示（比自己写alert更符合 ux）
监听 invalid 事件做细粒度反馈
invalid 事件在字段验证失败且浏览器准备显示默认提示前触发，但它**不会冒泡**，也不能被 preventDefault() 阻止默认提示——这点常被误以为能“接管”全部逻辑。它的真正用途是：在默认提示出现前，记录日志、标记 UI、或补充自定义文案。
注意：该事件只在表单提交时或显式调用 checkValidity()/reportValidity() 后触发，不会在用户每次输入时发生。
立即学习“Java免费学习笔记（深入）”；
- 给
绑定input.addEventListener('invalid', e => { ... }) - 此时
e.target.validationMessage是浏览器生成的提示文本（如 “请填写此字段”），可读但不可改 - 若想完全隐藏默认提示，得用
novalidate属性禁用原生验证，再全手动实现
用 setCustomValidity() 替换默认错误消息
当内置规则不够用（比如需要检查用户名是否已被注册），setCustomValidity() 是唯一能干预浏览器错误文案的 API。它不是“添加”校验，而是**覆盖**当前字段的验证状态和消息。
关键陷阱：传入空字符串 '' 才表示“校验通过”，任何非空字符串都会让字段变为无效状态（哪怕内容本身合法）。
const usernameInput = document.querySelector('#username'); usernameInput.addEventListener('blur', async () => { const value = usernameInput.value.trim(); if (!value) { usernameInput.setCustomValidity('用户名不能为空'); return; } // 模拟异步检查 const isTaken = await checkUsernameExists(value); if (isTaken) { usernameInput.setCustomValidity('该用户名已被占用'); } else { usernameInput.setCustomValidity(''); // ✅ 必须清空！否则一直 invalid } });避免混合验证导致状态混乱
同时使用 html 属性（如 required）、javaScript API（如 setCustomValidity()）和第三方库（如 Yup + Formik），极易出现验证状态不一致：比如字段明明填了却仍报 required 错，或自定义错误被 HTML 属性覆盖。
最稳妥的做法是二选一：要么纯用原生（HTML 属性 + checkValidity() + setCustomValidity()），要么彻底关闭原生验证（form.noValidate = true），再由 js 全权控制。
-
noValidate属性或form.noValidate = true会禁用所有原生校验，包括提交拦截 - 禁用后，
checkValidity()始终返回true，invalid事件不再触发 - 如果用了
pattern但又手动调用setCustomValidity()，后者优先级更高，但容易因忘记清空而锁死状态
复杂表单里，最容易被忽略的是异步校验完成后忘记重置 setCustomValidity('')，导致用户后续输入无法通过验证——这个空字符串不是可选的，是必须的开关。