JavaScript表单验证需兼顾时机、内容与反馈，纯前端仅防误需配合后端；应使用checkValidity()和reportValidity()结合HTML5约束，监听input/blur实现精准校验，并用setCustomValidity()自定义提示，同时注意disabled按钮、防重复提交及异步状态管理。
JavaScript 表单验证不是“加个 onsubmit 就完事”，关键在于**什么时候校验、校验什么、失败后怎么反馈**——纯前端验证只能防误，不能防恶意提交，必须配合后端；但用户侧体验好坏，全靠前端这层控制。
用 checkValidity() 和 reportValidity() 做基础校验
现代浏览器原生支持 HTML5 表单约束（required、type="email"、minlength 等），不用手写正则也能触发基础提示：
-
checkValidity()返回布尔值，只判断是否通过，不弹提示 -
reportValidity()不仅判断，还会在第一个无效字段上显示浏览器默认气泡提示（含本地化文案） - 两者都受
novalidate属性影响：表单加了novalidate，它们就失效 - 手动调用时，建议在
submit事件里用reportValidity()，失败时return false阻止提交
监听 input 和 blur 实现实时/失焦校验
用户填完立刻反馈，比等到点提交再报错体验好得多。但要注意触发时机和性能：
-
input事件适合实时反馈（如密码强度、邮箱格式），但别在里面做耗时操作（比如发请求） -
blur更适合语义完整校验（如用户名是否被占用、手机号是否合法），避免边打字边抖动提示 - 对同一个字段，可先
blur校验，之后再input中只做轻量检查（如长度、空格） - 别忘了清除之前的手动添加的
setCustomValidity()错误，否则checkValidity()会一直返回false
用 setCustomValidity() 自定义错误信息
原生提示太笼统（比如“请填写此字段”），用它可替换为具体指引：
- 传空
字符串
""表示“校验通过”，这是重置的关键 - 传非空字符串（如
"手机号格式不正确"）会让该字段checkValidity()返回false - 它不会自动触发 UI 提示，需搭配
reportValidity()或手动操作 DOM 显示 - 注意：如果字段有原生约束（如
required），setCustomValidity()会覆盖其默认错误，但不覆盖校验逻辑
避免常见陷阱：disabled 按钮、重复提交、异步校验状态管理
这些细节一漏，整个验证流程就断掉：
- 提交按钮别只靠 JS 禁用：
disabled状态要和表单有效性同步，且提交前仍需再调一次checkValidity()——因为用户可能绕过 UI 直接调 API - 防止重复提交：点击后立即
button.disabled = true，成功或失败后再恢复，别依赖 loading 状态遮罩 - 异步校验（如查用户名是否可用）必须管理加载态：
setCustomValidity("正在检查...")不生效，得自己加 loading 提示，并在响应回来后才调setCustomValidity("")或具体错误 - 所有校验逻辑不要假设 DOM 一定存在——SPA 页面切换时，监听器可能还在，但元素已销毁
最易被忽略的是：把校验结果缓存到变量里，而不是反复调 checkValidity()；以及忘记在表单重置（form.reset()）后手动清空自定义错误和自定义提示 DOM 节点。
