onblur失焦校验需满足可聚焦前提、规避浏览器兼容问题并配合防抖与阶段化策略；混用required须避免状态冲突，核心是根据上下文判断校验时机。
onblur 是最常用的失焦校验入口，但它不是“写上就生效”，得配合场景、状态和浏览器行为一起看。
为什么 onblur 有时根本没触发？
常见失效不是 JS 写错了，而是被忽略的基础前提：
-
disabled或readonly的<input>不会触发blur——它们压根不能获得焦点 - 用
focus()主动聚焦后立刻调blur()，在旧版 Safari 中会被静默丢弃；得包一层setTimeout(() => ..., 0)走微任务队列 - 移动端 iOS Safari 点击软键盘的 Done 键，可能不触发
blur（尤其在表单内有多个字段时）；建议补监听input或change事件兜底
onblur 校验该配什么策略才不干扰用户？
直接在 onblur 里跑正则或发请求，容易造成“刚输一半就报错”的体验。关键在节奏控制：
- 加防抖：延迟 300ms 执行校验逻辑，避免快速切换字段时误判
- 区分阶段：用
oninput做长度提示/格式初筛（如邮箱里有没有 @），onblur做最终格式校验（如完整邮箱正则、密码强度） - 跳过空值：如果字段允许为空，
onblur里先判断value.trim() === ''就直接返回，不走后续逻辑
和 required 原生校验混用要注意什么？
required 的校验时机和 onblur 完全不同，混用容易互相覆盖：
立即学习“前端免费学习笔记（深入）”；
-
required只在submit或显式调用checkValidity()时触发，它不监听blur；页面加载后留空也不会标红 - 如果同时写了
required和onblur校验，onblur报错后用户改完再点提交，原生required提示可能还卡在那儿（因为没重置状态） - 推荐做法：要么全用原生（靠
reportValidity()+ CSS:invalid控制样式），要么全用 JS 控制，别交叉管理验证状态
真正难的不是绑事件，而是判断“此刻该不该校验”——比如自动填充后焦点未真正离开、屏幕阅读器跳转顺序异常、动态下拉选择时 blur 先于 click 触发……这些边界情况，光靠 onblur 捕获不到，得结合上下文做状态同步。
