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 生命周期共同影响，过度依赖它，等于把业务逻辑绑在浏览器实现细节上。

前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！