应优先使用 reportvalidity() 触发原生校验，因其自动适配浏览器默认样式、焦点行为及无障碍支持；避免在 submit 中仅 preventdefault() 后手动校验，以免破坏原生体验。
直接用 reportValidity() 触发原生校验并显示提示，比手动遍历 checkValidity() + setCustomValidity() 更快、更可靠，且自动适配各浏览器默认样式和焦点行为。
为什么不要在 submit 事件里只用 preventDefault() + 手动判断
很多开发者会在表单 submit 事件中调用 event.preventDefault()，再逐个检查 input.checkValidity()，最后靠 input.setCustomValidity("xxx") 和 input.reportValidity() 模拟提示——这反而破坏了原生校验流程。浏览器此时已跳过默认的错误聚焦、气泡提示、无障碍朗读等关键体验。
正确做法是：让表单自然触发提交，仅在必要时干预。例如：
- 监听
submit事件，但不提前preventDefault() - 在事件处理器开头调用
form.reportValidity()（它会返回false并展示所有未通过字段的原生提示） - 若返回
false，说明有校验失败，直接return；否则继续执行自定义逻辑（如防重复提交、添加 loading）
pattern 和 title 必须成对出现才有效
pattern 属性本身不会显示任何提示，用户看到的只是“请与所要求的格式匹配”这类模糊文案。只有配合 title 属性，浏览器才会在悬停或验证失败时显示你写的友好说明。
常见错误写法：<input type="text" pattern="[0-9]{6}"> → 用户完全不知道要填什么
正确写法：<input type="text" pattern="[0-9]{6}" title="请输入6位数字验证码">
注意：title 不是装饰，它是校验失败时唯一可控的提示文本，且会被屏幕阅读器读出。
实时验证别滥用 input 事件，优先用 blur + 条件触发
对密码强度、邮箱格式这类复杂规则，在每次 input 事件里执行正则或异步检查，会导致卡顿、误报（比如用户刚输一半就标红），还干扰输入法上屏。
更合理的节奏是：
- 首次失去焦点（
blur）时触发一次校验 - 之后仅当用户再次修改且字段非空时，才在
input中轻量检查（如长度、必填） - 对高成本校验（如用户名是否已被注册），明确加「检查可用性」按钮，而非自动发起请求
这样既减少干扰，又符合用户心理预期：填完再看结果，而不是边打字边被否定。
禁用原生校验提示时，必须自己接管全部可访问性
有些项目用 novalidate 属性关闭整个表单的原生校验，然后全靠 JS 实现——这是高风险操作。一旦漏掉 aria-invalid="true"、aria-describedby 关联错误元素、或没处理键盘 Enter 提交后的焦点管理，就会让屏幕阅读器用户完全无法感知错误。
如果真要自定义样式和提示逻辑，至少确保：
- 每个输入框有
id，错误消息有对应id，并通过aria-describedby显式关联 - 校验失败后，用
element.focus()主动聚焦第一个错误项 - 错误消息使用
role="alert"或动态插入到live region中，保证被朗读
原生校验不是“不够酷”，而是经过多年打磨的兼容性与无障碍基线。绕开它，就得亲手补全整条链路。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
