HTML5验证属性仅支持基础静态约束，无法处理字段联动、条件校验、异步验证等业务逻辑，必须结合JavaScript实现完整校验流程。
HTML5验证属性只能做基础约束，不能替代逻辑判断
像 required、pattern、minlength 这类属性，本质是浏览器对单个字段的“静态规则拦截”，它不感知上下文、不联动其他字段、也不支持条件分支。比如“确认密码”必须和“密码”一致，或者“国家选择为中国时，手机号才需匹配 /^1[3-9]\d{9}$/”，这些都超出 HTML 属性能力范围。
常见错误现象是：开发者把所有规则都堆进 pattern，结果正则越写越长，可读性归零，改一个字符就全崩；或误以为加了 required 就等于“用户一定填了有效值”，忽略了空格、全角字符、粘贴带换行等真实输入场景。
- HTML 验证只在表单提交（或调用
checkValidity()）时触发，不会响应实时输入变化 -
pattern的正则默认是全字符串匹配（即隐式带^...$），但不支持标志位如i或g，也不能捕获分组用于后续提示 - 不同浏览器对
setCustomValidity()的错误提示展示位置、样式、延迟时间不一致，移动端尤其不可靠
用 checkValidity() 和 reportValidity() 衔接原生与自定义逻辑
不要直接监听 submit 后再手动遍历每个 input 做 .value 判断——这会绕过浏览器已有的原生校验（比如 type="email" 的格式检查），导致重复劳动且体验割裂。正确做法是先让浏览器跑一遍原生校验，再基于结果叠加业务逻辑。
示例场景：邮箱字段已设 type="email" 和 required，但还需检查该邮箱是否已被注册。此时应：
立即学习“前端免费学习笔记（深入）”；
- 在
submit事件中先调用form.checkValidity()，若返回false，说明原生校验失败，直接退出（让浏览器显示默认提示） - 若返回
true，再发起 AJAX 检查邮箱唯一性；失败时对对应input调用setCustomValidity('该邮箱已被注册')，然后调用form.reportValidity()触发错误提示 - 注意：每次调用
setCustomValidity()后，必须在验证通过时重置为''，否则后续提交会持续失败
复杂联动校验必须用 JavaScript 实时监听 + 状态缓存
涉及多个字段依赖的场景（如“支付方式选‘银行卡’时，卡号、开户行必填；选‘支付宝’时，账号格式需匹配邮箱”），HTML 属性完全无能为力。这类逻辑必须由 JS 主导，且不能只靠提交时一次性校验——用户需要即时反馈。
关键点在于状态管理：
- 用
data-state或 Map 缓存每个字段当前是否“通过校验”，避免重复计算 - 监听
change或blur事件更新依赖字段的状态，比如切换下拉框后，立即清空并隐藏关联字段的错误提示 - 对异步校验（如用户名可用性），要处理加载态（禁用提交按钮）、防抖（避免高频请求）、超时 fallback
- 别用
oninput做耗时校验（如正则匹配长文本），容易卡顿；优先用blur或防抖后的input
移动端和无障碍访问下，HTML 属性的局限更明显
在 iOS Safari 或安卓 WebView 中，pattern 对中文输入法兼容差，用户还没输完就报错；reportValidity() 的弹窗可能被软键盘遮挡；而屏幕阅读器对原生错误提示的支持程度参差不齐。
因此，哪怕用了 HTML5 属性，也必须用 JS 构建一套独立的、可访问的错误提示系统：
- 每个输入框旁配一个
<span class="error" aria-live="polite"></span>，JS 动态写入错误文案 - 出错时给
input加aria-invalid="true"和aria-describedby指向错误容器 - 不要依赖
:invalidCSS 伪类做核心提示逻辑，它在部分安卓浏览器中不触发重绘 - 测试真机输入：长按粘贴、语音输入、九宫格拼音，这些都会绕过
pattern的即时拦截
