应优先使用 reportvalidity() 实现提交时验证，它会返回布尔值并触发原生错误气泡、高亮所有无效字段，且等价于用户点击提交的默认行为；checkvalidity() 仅返回布尔值，不触发 ui 提示。
表单提交前用 checkValidity() 触发原生验证
HTML5 表单自带的验证逻辑（如 required、type="email"、pattern）不会自动在提交时弹出提示，除非你显式调用 checkValidity() 或依赖浏览器默认行为。很多开发者直接监听 submit 事件却忘了阻止默认行为并手动触发验证，结果导致表单绕过校验直接提交。
正确做法是在 submit 事件处理器中调用 form.checkValidity()，它会返回 true 或 false，同时自动在首个无效字段上显示浏览器原生提示（如红色边框 + tooltip）。
- 必须配合
event.preventDefault()，否则表单可能在验证失败后仍刷新页面 -
checkValidity()不会触发invalid事件，但会激活:invalidCSS 伪类 - 若需自定义错误消息，应改用
setCustomValidity()配合reportValidity()
用 reportValidity() 强制显示所有验证反馈
checkValidity() 只返回布尔值，不强制弹出 UI 提示；而 reportValidity() 在返回 false 时，会触发浏览器原生错误气泡（bubble），且对所有无效字段一并高亮 —— 这是更贴近用户预期的“提交时验证”行为。
它等价于用户手动点击提交按钮时的默认验证流程，但可由 JS 主动触发，适合在禁用默认提交、改用 AJAX 的场景下补全体验。
- 调用
form.reportValidity()后，若验证失败，会返回false，此时可跳过后续提交逻辑 - 它会触发每个无效字段的
invalid事件，可用于埋点或日志记录 - 注意：Safari 15.4+ 才完整支持
reportValidity()对fieldset内嵌表单的处理
监听 invalid 事件做细粒度控制
当某个字段验证失败时（无论是用户失焦、输入过程还是 reportValidity() 调用），浏览器会派发 invalid 事件。这个事件**不会冒泡**，所以必须直接绑定到具体 <input> 或使用事件委托捕获（通过监听父元素的 invalid 并检查 event.target）。
常见误操作是把它当成普通事件去监听整个表单，结果收不到任何回调。
- 可在
invalid回调中调用event.target.setCustomValidity("手机号格式错误")覆盖默认提示 - 搭配
event.preventDefault()可阻止原生气泡，实现纯自定义 UI 提示 - 注意：重复调用
setCustomValidity("")才能清除自定义错误状态，否则该字段始终视为无效
避免 input 实时验证引发的性能与体验问题
有人喜欢在 input 或 keyup 事件里频繁调用 checkValidity()，这会导致每敲一个字都触发验证、重绘和潜在的 DOM 操作，尤其在长文本或正则复杂字段（如 pattern="^[\u4e00-\u9fa5a-zA-Z0-9_]{2,10}$"）中明显卡顿。
更合理的方式是分场景响应：
- 邮箱、URL 类字段可用
blur触发一次验证（用户离开时） - 密码确认类字段建议在目标字段
input后加防抖（如 300ms），而非即时 - 如需实时反馈，优先用 CSS
:valid/:invalid控制样式，而非 JS 查询状态 - 复杂业务规则（如“用户名不能为已注册邮箱”）必须延迟到提交前或
blur后用异步校验，不能塞进实时事件
动态验证真正的难点不在代码量，而在于判断「什么时候验证」和「验证失败后要不要阻断交互」—— 浏览器原生 API 已足够好用，但滥用 setCustomValidity() 或忽略事件冒泡特性，最容易让验证逻辑失控。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
