原生HTML5表单校验需结合JavaScript与Constraint Validation API才能可靠落地：pattern须用^$锚定全匹配；setCustomValidity()需配对清空；实时验证应防抖或改用blur；checkValidity()仅判断，reportValidity()才触发提示。
原生 HTML5 表单校验撑不住复杂业务逻辑，必须配合 JavaScript 和 Constraint Validation API 才能可靠落地。
pattern 属性的正则陷阱：浏览器不报错但匹配失效
很多人以为 pattern 加上正则就万事大吉，实际中常遇到“明明写了正则，却没触发校验”或“输入错误内容却通过了”。根本原因是：pattern 默认只做**部分匹配**，不强制全字符串匹配。
- 错误写法：
<input pattern="[0-9]{5}">—— 输入"12345abc"也能通过（因为开头 5 位匹配） - 正确写法：
<input pattern="^[0-9]{5}$">——^和$强制首尾锚定，确保整个值符合 - 注意：浏览器不会在控制台报正则语法错误，失败时只表现为“无校验效果”，排查要先检查锚点
- 移动端 Safari 对某些 Unicode 正则支持较弱，如中文手机号验证建议用
[\u4e00-\u9fa5]而非\p{Han}
setCustomValidity() 必须配对调用，否则表单永久 invalid
setCustomValidity() 是接管校验结果的关键方法，但它的状态是**持久化**的：一旦设为非空字符串，该字段就一直保持 validity.valid === false，直到你显式清空。
- 常见错误：只在出错时调用
input.setCustomValidity('密码不一致')，却忘了在输入正确时调用input.setCustomValidity('') - 后果：用户改对了，
checkValidity()仍返回false，提交被阻断 - 安全写法：每次
input或blur事件中，先清空再判断重设：input.addEventListener('input', () => { input.setCustomValidity(''); // 先清空 if (!matchesPasswordConfirm()) { input.setCustomValidity('两次输入的密码不一致'); } }); - 不要依赖
reportValidity()自动清空——它只触发提示，不重置状态
实时验证 vs 提交验证：别在 input 事件里做耗时校验
监听 input 做实时反馈很爽，但若在其中执行网络请求、复杂正则匹配或 DOM 遍历，会直接卡住输入体验。
立即学习“前端免费学习笔记（深入）”；
- 典型反模式：
input事件里调用fetch('/api/check-username?name=xxx')—— 用户每敲一个字就发请求，既浪费资源又容易超时 - 合理做法：对用户名查重这类操作，改用
blur触发，或加防抖（debounce）延迟 300ms 后执行 - 密码强度实时反馈可用轻量计算：
/[a-z]/.test(val) && /[A-Z]/.test(val) && /d/.test(val)，避免用RegExp.test()多次编译 - 注意：Chrome 对频繁调用
setCustomValidity()有性能优化，但 Safari 未完全跟进，高频调用仍可能引发 layout thrashing
checkValidity() 和 reportValidity() 的分工必须明确
这两个方法常被混用，但语义和副作用完全不同，错用会导致提示缺失或重复弹窗。
-
form.checkValidity()：纯判断，返回布尔值，**不触发任何 UI 提示**，适合逻辑分支控制 -
form.reportValidity()：判断 + **主动触发浏览器原生气泡提示**，只应在用户明确想提交但被拦住时调用（如点击提交按钮后） - 错误组合：
if (!form.checkValidity()) form.reportValidity()在submit事件里是冗余的——浏览器默认就会做这事；真正需要的是e.preventDefault()+ 自定义提示 - 关键细节：只有
reportValidity()会让焦点自动跳转到第一个无效字段，checkValidity()不会
复杂业务校验真正的难点不在写多少规则，而在于状态同步：HTML 属性、JavaScript 变量、DOM 提示、焦点管理这四者稍有脱节，用户就会陷入“我明明改对了，为什么还报错”的困惑。每次修改校验逻辑，务必手动测试 blur → 修改 → 再 blur 这个闭环。
