JavaScript表单验证需协调原生校验与JS逻辑：用checkValidity()静默判断、reportValidity()触发原生提示；submit事件中preventDefault()后校验，避免绕过无障碍支持；pattern要求全值匹配，JS正则须加^$锚点；移动端需在submit统一校验并监听focusout。
JavaScript 表单验证不是“加个 onsubmit 就完事”，关键在于**何时校验、校验什么、以及如何反馈**——尤其要注意浏览器原生校验（required、type="email"）和 JS 手动校验的冲突与协作。
用 checkValidity() 和 reportValidity() 控制原生校验行为
现代浏览器对 input 元素的 required、minlength、pattern 等属性有内置校验逻辑，但默认只在表单提交时触发。若你想在用户离开字段时就提示，或阻止默认提交流程后再自定义提示，就得介入：
-
element.checkValidity()返回布尔值，不弹出气泡提示，适合静默判断 -
element.reportValidity()触发浏览器默认错误气泡（含本地化文案），且返回布尔值，适合“手动唤起原生反馈” - 直接监听
input或blur事件调用reportValidity()会导致重复提示（比如用户还没输完就 blur），建议搭配:user-invalidCSS 伪类或标记“已交互”状态来节流
避免 onsubmit 中直接 return false 的陷阱
很多人写 ，然后在 validate() 里做 JS 校验并 return false。这会完全绕过浏览器原生校验，丢失无障碍支持和移动端键盘“完成”按钮行为：
- 正确做法是监听
submit事件，调用event.preventDefault()，再执行校验逻辑 - 校验失败后，手动聚焦首个错误项：
firstInvalidInput.focus()，提升可访问性 - 若部分字段依赖异步校验（如用户名是否已存在），必须阻断同步提交，用
Promise+async/await控制流程，不能靠return false撑住
正则校验 pattern 属性 vs RegExp.test() 的差异
pattern 属性值是一个正则字符串（不带 /g 标志），浏览器会自动添加 ^ 和 $ 锚点，即要求**整个输入值完全匹配**；而 JS 中 /\d+/.test("123abc") 会返回 true，因为没加锚点：
立即学习“Java免费学习笔记（深入）”；
- 保持一致性：JS 校验也应使用
/^\d+$/.test(value)，否则前后规则不一致 -
pattern不支持标志如i（忽略大小写），需写成[a-zA-Z]；JS 中可用/abc/i - 密码强度校验等复杂逻辑无法用
pattern表达，必须用 JS，此时建议统一用RegExp实例复用，避免每次新建正则对象
移动端软键盘收起后验证失效的典型场景
在 iOS Safari 中，用户点击软键盘“完成”按钮，有时不会触发 blur，导致你绑定在 blur 上的校验没执行；而 submit 又可能被原生校验抢先拦截：
- 保险做法：在
submit事件中对所有必填字段统一调用checkValidity()，再结合自定义逻辑 - 监听
focusout而非blur（前者冒泡，后者不冒泡），便于在父容器上委托处理 - 不要依赖
change事件——它在失去焦点且值改变后才触发，对空输入或快速切换无效
真正难的不是写校验函数，而是让校验时机、反馈方式、错误定位三者对齐，同时不破坏原生体验。尤其当表单混用原生属性和 JS 逻辑时，一个 novalidate 属性漏加，或一次 preventDefault() 多写，整个验证链就断了。
