原生校验API需手动集成异步流程：submit时preventDefault，先reportValidity执行本地校验，再发请求，成功则清空并提交，失败则setCustomValidity并reportValidity；pattern/type需严格锚定且动态字段须JS桥接。
原生校验 API 不是“开箱即用”的验证框架，而是浏览器提供的底层控制接口；直接依赖 required、pattern 或 setCustomValidity() 而不干预触发时机，大概率在异步、跨字段或服务端联动场景下失效。
为什么 setCustomValidity() 在 fetch 回调里总没反应
它不是实时绑定的响应式状态，而是一次性快照：浏览器只在 checkValidity()、reportValidity() 或表单 submit 时读取当前值。你在 fetch().then() 里调用 input.setCustomValidity('已存在')，此时用户可能早已提交、跳转或切走了焦点——回调根本没机会影响验证流。
- 并发请求下多次调用
setCustomValidity()会相互覆盖，只剩最后一次生效 - 没在新请求发起前清空旧状态：
input.setCustomValidity('')缺失 → 上次错误文案残留，干扰后续输入 -
validity.valid始终为true，因为校验根本没被重新触发；你得手动调reportValidity()才会刷新 UI 和 validity 状态
怎样让异步校验真正接入原生验证流
核心是放弃“等浏览器自动触发”，改为监听 submit、主动阻断、分阶段执行：本地规则先过，再发请求，最后由 JS 决定是否放行。
- 给
<form>绑定submit事件，第一行必须写e.preventDefault() - 对每个需异步校验的字段，先调
input.reportValidity()—— 这会触发required/pattern/min/max 等原生检查，失败则中断流程 - 本地通过后发请求；成功且业务允许 →
input.setCustomValidity('')+form.submit()；失败 →input.setCustomValidity('用户名已被占用')+input.reportValidity() - 每次请求开始前必须
input.setCustomValidity('')，否则残留错误会卡住整个流程
pattern 和 type="email" 的宽松陷阱怎么填
它们只做最基础的格式识别，离业务可用差很远。
立即学习“前端免费学习笔记（深入）”；
-
type="email"只认a@b.c就算合法；真要校验，改用type="text"+pattern="^[a-z0-9._%+-]+@[a-z0-9.-]+\.[a-z]{2,}$"+title提示文案 -
pattern="[0-9]{4}"允许abc1234def过关，因为没锚定边界；必须写成pattern="^[0-9]{4}$" -
type="number"对粘贴字母完全不拦截，且checkValidity()可能返回true（值为空字符串""但 validity 仍认为有效）；得配合min/max或额外判断input.value !== '' -
novalidate只能加在<form>上，加在<input>上无效
最容易被忽略的是：动态插入的字段（比如 Vue/React 渲染的 input）、富文本框、自定义组件，都不在原生验证流中——form.reset() 和 reportValidity() 完全感知不到它们的存在，必须用 JS 手动桥接状态。
