blur是监听表单失焦的事件，但易误用：移动端键盘收起、submit/reset后、动态插入元素未挂载、隐藏元素及blur中focus()均导致其不可靠；宜用于轻量标记，关键逻辑应改用input防抖、focusout或submit事件。
blur 是监听表单元素失焦的正确事件，但它极易误用——不是所有“看起来失焦”的情况都会触发它，也不是所有场景都适合在 blur 里写逻辑。
blur 事件为什么有时不触发？
常见失焦“假象”根本不会触发 blur：
- 移动端软键盘收起 ≠ 失焦：iOS Safari、部分安卓 WebView 中点击「完成」或「收起键盘」，
blur可能延迟、丢失，甚至完全不触发 - 表单
submit()或reset()后焦点自动清空，但这是同步行为，blur不一定来得及冒泡或执行 - 动态插入的
input（如模态框内）若未挂载完成就调用focus()，后续blur可能无法建立监听链 - 元素被
display: none或visibility: hidden隐藏后，浏览器可能跳过焦点管理，blur不再可靠
blur 里调用 focus() 会出什么问题？
试图在 blur 回调中立刻 input.focus() 来“阻止失焦”，实际只是事后拉回，副作用明显：
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- 视觉闪烁：尤其在快速 Tab 切换时，焦点来回跳，用户感知突兀
- 破坏辅助技术：屏幕阅读器依赖稳定的焦点流，硬聚焦会打断其导航顺序
- 异步聚焦（如
setTimeout(() => input.focus(), 0)）可能被用户下一次点击直接覆盖，行为不可控 -
event.preventDefault()在blur中完全无效——它不能被阻止，只能补救
什么时候该用 blur，什么时候该换别的？
blur 的合理定位是“轻量标记”，不是“关键动作触发点”：
立即学习“前端免费学习笔记（深入）”；
- 适合做：标记字段“已被访问过”、清除临时帮助文案、做基础格式校验（如邮箱是否含 @）
- 不适合做：提交表单、触发网络请求、强依赖“用户已完成输入”——因为用户可能只是切到密码框，还没填完
- 更稳的替代组合：
input+ 防抖（debounce）用于实时响应；focusout（冒泡版blur）用于父容器统一监听；submit事件里做最终校验 - 对必须响应“结束输入”的场景，可结合
document.activeElement判断是否真离开了当前表单域，而非只信blur
真正容易被忽略的是：blur 不是“用户操作终点”，而是浏览器焦点调度中的一个中间信号。它的触发时机受平台、渲染队列、DOM 生命周期共同影响，过度依赖它，等于把业务逻辑绑在浏览器实现细节上。
