focusin 比 focus 更可靠，能捕获所有聚焦来源（包括 autofocus、js focus()、点击图标等），且冒泡支持父容器统一监听；focus 不冒泡且不响应程序化聚焦，ios safari 还忽略 autofocus。
onfocus 是最直接的监听方式，但它只在用户主动点击或按 Tab 进入时触发，不响应 autofocus 属性或 JS 调用 .focus() 后的“程序化聚焦”——后者需额外监听 focusin 才能捕获。
focus 事件不触发？检查是否被 autofocus 或 JS 覆盖
页面加载后 input 没有执行 onfocus 回调，大概率是因为：autofocus 属性虽让元素获得焦点，但不会触发 focus 事件（规范明确要求）；同理，JS 中调用 input.focus() 若发生在 DOM 尚未可交互阶段（如 DOMContentLoaded 前），也可能静默失败。
- 确保绑定监听在
DOMContentLoaded或框架的挂载钩子（如 Vue 的onMounted、React 的useEffect(() => {}, [])）之后 - 若用了
autofocus，又想统一处理聚焦逻辑，改用focusin事件——它冒泡且能捕获所有来源的聚焦（包括autofocus和.focus()） - 移动端 iOS Safari 对
autofocus几乎总是忽略，别依赖它来触发业务逻辑
focusin 比 focus 更可靠，尤其在动态场景下
focusin 是冒泡事件，focus 不冒泡。这意味着你可以把监听器挂在父容器上，一次绑定覆盖多个输入框，也更容易捕获由图标点击、按钮联动等间接触发的聚焦。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 用
focusin替代focus：它会在元素真正获得焦点时触发，无论来源是鼠标、键盘、JS 还是autofocus - 注意：IE9+ 支持
focusin，但旧版 IE 需用focus+attachEvent兼容写法（现基本可忽略） - 避免在
focusin处理器里立即调用input.select()或弹出软键盘——部分安卓 WebView 会因时机过早导致异常
点击搜索图标也要触发聚焦？别只靠 CSS :focus
常见布局中，搜索图标用 <button></button> 或 <img> 绝对定位在 input 右侧，此时点击图标本身不会让 input 获得焦点——因为图标不是可聚焦元素，也无法通过 :focus 伪类联动样式。
- 给图标容器（如
<button class="search-btn"></button>）加tabindex="0"，使其可聚焦 - 在 JS 中监听该按钮的
click或focusin，然后显式调用input.focus() - 如果要用纯 CSS 实现展开效果，必须让图标和
input是相邻兄弟关系，并用.search-btn:focus ~ .search-input规则——但这无法触发 JS 逻辑，仅限样式控制
focus 事件里不能做的事
聚焦瞬间不适合做重操作，尤其是涉及 DOM 修改、网络请求或第三方 SDK 初始化。浏览器可能尚未完成焦点切换动画，或正忙于软键盘调度，强行操作易导致状态错乱。
- 不要在
focus回调里调用input.select()后立刻document.execCommand('selectAll')（已废弃且不可靠） - 避免同步发起 API 请求——用户可能刚点进来就切走了，造成无效请求
- 若需清空提示文案或高亮边框，优先用 CSS
:focus-within或:focus类控制，JS 仅作补充 - 特别注意中文输入法场景：聚焦后用户可能立刻进入拼音组合状态，此时
input.value还是空的，别误判为“未输入”
真正容易被忽略的是：聚焦事件本身不携带“这次聚焦是否来自用户操作”的元信息。你无法区分是用户点了 input，还是 JS 脚本调了 .focus()，更无法知道是不是自动填充触发的——这些边界情况必须靠业务层埋点或状态标记来补全。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
