HTML5原生required和pattern适用于非空、邮箱格式、最小长度等基础校验，但仅提交时触发且样式文案不可控；required只判空字符串，pattern需用^$确保全匹配，type="email"不验域名有效性。
HTML5 原生 required 和 pattern 能解决哪些验证场景？
浏览器自带的表单验证轻量、无需 JS，适合基础校验。比如邮箱格式、非空、最小长度等，但仅触发在提交时，且样式和提示文案不可控。
-
required只检查值是否为空字符串（不校验空格、null 或 undefined） -
pattern接收正则，但注意：它默认是「部分匹
配」，建议用
^...$包裹确保全匹配 -
type="email"仅做简单格式检查（如含 @），不验证域名有效性 - 提交失败时会调用
reportValidity()显示气泡提示，但无法拦截或自定义内容
示例：
用 addEventListener('input') 实时验证时要注意什么？
实时验证体验好，但容易误判——比如用户刚敲第一个字符就报错。关键不是“每输一个字都校验”，而是“在合适时机反馈”。
- 避免对每个
input事件都调用setCustomValidity()，否则会干扰原生验证状态 - 推荐策略：监听
input做视觉反馈（如加红边、显示提示），但只在submit或失去焦点（blur）时才真正判定有效性 - 注意中文输入法未完成时（compositionstart → compositionend 之间）的
input事件可能携带不完整文本，可加标志位忽略
常见错误：element.setCustomValidity('') 必须显式调用才能清除错误态，否则后续 checkValidity() 一直返回 false
checkValidity() 和 reportValidity() 的区别与配合方式
这两个方法常被混用，但职责不同：前者只返回布尔值，后者会触发 UI 提示并返回布尔值。
-
form.checkValidity()返回整体是否有效，但不展示任何提示 -
form.reportValidity()会遍历所有无效字段，显示浏览器默认气泡，并返回false（即使只有一个错） - 若想自定义提示（比如用 tooltip 替代气泡），应只用
checkValidity()判断，再手动控制 UI，同时调用element.setCustomValidity('错误信息')维持表单级有效性状态
注意：调用 setCustomValidity('') 后必须再次调用 reportValidity()（或触发 submit）才能让浏览器重新评估并隐藏气泡
复杂规则（如两次输入密码一致、手机号归属地校验）为什么不能只靠 HTML 属性？
HTML5 属性只能描述静态规则，无法处理字段间依赖或异步逻辑。
- 两次密码一致：需监听两个
input，比对value，并调用confirmInput.setCustomValidity()动态设错 - 手机号校验：要请求后端接口判断号段，此时必须禁用原生提交，用 JS 控制流程，避免用户重复点击
- 异步校验中，需设置加载态、防重复提交、失败后保留用户输入（不要清空）
关键点：只要涉及跨字段或异步，就必须用 JS 主导验证流程，HTML 属性仅作辅助降级或初始约束
表单验证真正的复杂点不在写法，而在「什么时候反馈」和「反馈后怎么恢复」——比如用户改完错误字段，是否自动清除提示？输入过程中要不要抑制提示？这些细节没处理好，体验反而比不验证更差。
