排查自定义校验与html5原生校验冲突的“死循环”，需依次检查：css伪类误维持错误态、setcustomvalidity()未清空导致customerror恒为true、submit事件重复绑定或未阻止默认行为、validitystate中具体哪项持续为true。
排查自定义校验与 HTML5 原生校验冲突引发的“死循环”，核心是识别出哪些行为在反复触发、互相干扰——比如输入后红框不消失、错误提示闪退又弹出、修改正确值后 checkValidity() 仍返回 false、表单无法提交等。这类问题不是代码写错了，而是验证时机、状态管理、API 调用顺序没对齐。
看 CSS 是否偷偷“续命”了原生校验
即使加了 novalidate，浏览器仍会动态设置 :invalid 和 :valid 伪类。如果你的样式表里写了：
input:invalid { border: 1px solid #e53935; }input:user-invalid { background: #fff8f8; }
那视觉上就永远像“还在校验”。用户改对了，但样式没更新，误以为失败；更糟的是，有些 JS 逻辑会监听 input.validity.valid 或轮询 checkValidity()，结果一直卡在 false。
解法：临时注释掉所有含 :invalid、:user-invalid 的 CSS 规则，刷新页面看是否恢复正常。若恢复，说明样式层在“假性维持错误态”，需配合 JS 主动重置状态（见下一条）。
查 setCustomValidity() 是否漏清空
setCustomValidity() 是一次性快照，设了错误文案后不会自动清除。哪怕用户已输对，只要没调 input.setCustomValidity('')，该字段就始终处于“自定义无效”状态，checkValidity() 永远返回 false，形成逻辑死锁。
常见场景：
- 异步校验（如用户名查重）成功回调里只写了
setCustomValidity('已存在')，却忘了在“通过”分支里写setCustomValidity('') - 监听
input实时校验，但只在失败时设错误，没在每次输入都先清空旧状态 - 多个校验逻辑（如格式 + 唯一性）共用一个 input，A 逻辑清空了，B 逻辑又设上了，来回覆盖
解法：所有校验入口的第一行，强制加 input.setCustomValidity('')；异步请求发起前必须清空；服务端返回后，无论成功失败，都要明确设置一次（成功设空，失败设文案）。
验事件监听是否重复绑定或未阻止默认
死循环常发生在 submit 处理中：你监听了 submit，调了 e.preventDefault()，做了自定义校验，最后手动 form.submit() ——但这个手动提交又再次触发了同一个监听器，造成递归。
另一个高频坑是：同时绑了原生 required 和 JS 校验，又没在 submit 里统一拦截，导致浏览器先弹原生气泡，JS 再弹 toast，用户点一次提交，两个提示叠着来，误操作后状态混乱。
解法：
- 检查是否多次执行
form.addEventListener('submit', handler)，可用console.log('submit bound')确认只绑一次 - submit 回调开头必须写
e.preventDefault()，且全程不再调用form.submit()（除非你明确需要二次提交） - 若要用 JS 控制提交，改用
fetch+ 手动清空/跳转，绕过表单原生提交流
抓实时 validity 状态变化链
浏览器的 ValidityState 对象（input.validity）是多个布尔值的集合：valueMissing、typeMismatch、patternMismatch、customError 等。死循环往往源于某一项始终为 true，而你没意识到它被谁设上的。
实操步骤：
- 打开 DevTools → Elements 面板，选中问题 input
- 在 Console 中输入
$0.validity，观察哪几项为true - 若
customError: true，说明setCustomValidity()没清空 - 若
valueMissing: true但值不为空，可能是值含首尾空格或全角字符，需.trim() - 若
patternMismatch: true，检查 pattern 正则是否真能匹配当前值（注意隐式^$锚定）
定位到具体 validity 项后，就能反向追踪是哪个环节没处理干净。
