应直接监听表单 submit 事件并调用 preventDefault() 阻止默认提交，再执行 JS 验证；required 和 pattern 适用于基础校验，复杂逻辑必须用 JS；checkValidity() 和 reportValidity() 仅支持原生约束且提示不可控；错误提示需靠近字段、适时触发、及时清除关联状态。
怎样用 addEventListener 捕获表单提交行为
直接监听 submit 事件比监听按钮点击更可靠，因为用户可能按回车提交，或通过辅助工具触发。必须调用 event.preventDefault() 阻止默认跳转或刷新，否则验证逻辑还没执行表单就已提交。
- 只对
<form>元素绑定，不要绑在按钮上 - 避免重复绑定：多次执行同一段绑定代码会导致验证函数被调用多次
- 移动端需注意：部分安卓 WebView 对
submit事件触发时机有延迟，可加input或blur作补充校验
document.querySelector('form').addEventListener('submit', function (e) {
e.preventDefault();
if (validateForm()) {
this.submit(); // 手动提交，绕过再次触发 submit 事件
}
});
哪些字段该用 required、pattern 还是 JS 手动检查
浏览器原生属性适合基础约束，但别全依赖它——required 只检查是否为空，不校验格式；pattern 仅支持单行正则，且错误提示不可控；复杂逻辑（如密码强度、两次输入比对、异步用户名唯一性）必须用 JS。
-
required：适用于所有必填项，如<input required> -
pattern：仅用于简单格式，比如手机号：<input pattern="^1[3-9]\d{9}$">，但不校验区号或虚拟号段 - JS 校验：邮箱域名有效性、密码含大小写字母+数字+符号、确认密码与原始密码一致等
为什么 checkValidity() 和 reportValidity() 不够用
这两个方法能触发原生校验 UI（红边框 + tooltip），但它们只响应 HTML5 表单属性（required、minlength 等），对自定义规则无反应；且 reportValidity() 会打断用户操作流，无法和自定义错误消息共存。
- 调用
reportValidity()后，焦点会自动跳到第一个无效字段，干扰多步骤表单体验 - 某些场景下（如动态增删字段），
checkValidity()返回true，但业务逻辑仍要求拦截（例如“至少选中两项”） - 国际化项目中，原生提示语无法替换，必须手动控制
setCustomValidity()并配合 JS 显示翻译后文案
怎样让错误提示既清晰又不打断填写流程
验证不该只在提交时发生。理想做法是：输入完成（blur）时轻量校验，提交时全量校验；错误信息要靠近对应字段，避免只弹 alert 或堆在顶部。
立即学习“Java免费学习笔记（深入）”；
- 每个
<input>下紧跟一个<small class="error">，JS 动态更新其textContent - 校验通过后清空错误文案，并移除
aria-invalid="true"和错误 class - 对密码确认类字段，要在两个字段都输完后再比对，避免一边没输就报错
const pwd = document.getElementById('password');
const confirm = document.getElementById('confirm-password');
confirm.addEventListener('blur', () => {
if (confirm.value && confirm.value !== pwd.value) {
confirm.setCustomValidity('两次输入的密码不一致');
} else {
confirm.setCustomValidity('');
}
});
原生表单验证只是起点，真正健壮的交互取决于你何时介入、如何反馈、以及是否预留了服务端兜底。最常被忽略的是：**用户改完一个字段后，相关联字段的错误状态没及时清除**，比如改了邮箱，但“邮箱已注册”的提示还挂着——这需要你在关键字段变更时主动重置关联校验。 
