javaScript表单验证需分input、blur、submit多时机协同：input实时轻量校验并防抖，blur做语义及异步校验（配loading与abortController），submit最终守门并禁用默认行为。
javascript 表单验证的核心不是“全写在 submit 事件里”，而是把验证逻辑拆到 input、blur、change 和 submit 多个时机，配合实时反馈和防重复提交。
用 addEventListener('input') 实时监听输入变化
用户每敲一个键就触发验证，适合长度、格式类检查（如邮箱、手机号）。注意别在 input 里直接弹 alert 或重绘整个表单，容易打断操作。
实操建议：
- 对
type="text"、type="email"等字段，优先用input事件做轻量校验（比如非空、最小长度） - 避免在
input中执行耗时正则（如超长中文邮箱匹配），可加setTimeout防抖，延迟 300ms 再验证 - 验证失败时，只修改对应字段的
className（如加Error）、更新紧邻的文本，不隐藏/显示其他区域
用 addEventListener('blur') 做离开焦点时的语义校验
blur 是用户填完一个字段后移开焦点的信号，适合需要完整值才能判断的场景（如两次密码一致、用户名是否已被注册）。
立即学习“Java免费学习笔记（深入）”；
常见错误现象：
- 用户还没输完就点了别的输入框，
blur触发但值为空，误报“不能为空”——应先判断value.trim() !== ''再走业务规则 - 异步校验（如查用户名是否可用）没置 loading 状态，用户连续点两次提交按钮，发起两个请求——需在发起请求前设
isChecking = true，响应后才重置 - 后端返回 400 错误但前端没解析
response.body.message，只显示“校验失败”——建议后端统一返回{ field: "username", message: "已被占用" }，前端按field定位并提示
submit 事件里必须做最终守门，且禁用默认提交
无论前面做了多少实时反馈，submit 事件中仍要重新跑一遍所有字段的验证逻辑。因为用户可能绕过前端（如禁用 js、用 curl 提交），或篡改 dom 移除了 error class。
实操要点：
- 第一行必须写
event.preventDefault()，否则页面会刷新或跳转 - 不要只依赖 css 类判断是否通过，应调用统一验证函数（如
validateForm()）返回布尔值 - 验证失败时，聚焦第一个出错字段：
document.querySelector('.error input').focus()，提升可访问性 - 按钮添加
disabled属性防重复点击，提交成功或失败后才恢复：button.disabled = true
浏览器原生 checkValidity() 和 setCustomValidity() 要慎用
它们能快速启用 html5 表单约束（required、minlength），但行为不一致：chrome 会在 submit 时自动弹原生气泡，safari 可能不触发 invalid 事件，而且无法自定义样式。
使用场景与限制：
- 仅用于简单静态规则（如
required、type="email"），别用来替代业务逻辑（如“密码不能包含用户名”） - 若用了
setCustomValidity("xxx")，每次输入都得调用setCustomValidity("")清空，否则后续checkValidity()永远返回 false - 和第三方 UI 库（如 Element Plus、Ant Design）混用时，原生验证常与组件内部状态冲突，建议关闭：
novalidate属性 + 完全手写验证
最易被忽略的是异步校验的竞态问题：用户快速修改「确认密码」字段多次，多个 blur 触发的请求返回顺序不确定，可能导致旧响应覆盖新响应，显示错误提示。解决方法不是加锁，而是为每次请求生成唯一 abortController，在新请求发起前 abort 上一个。