input失焦非故障而是规范行为，问题多源于事件干扰、dom状态不匹配或移动端限制；修复需控制时机、规避默认行为冲突，并满足focus()调用的四个前提条件。
input 元素失焦不是“坏了”，而是浏览器在按规范执行焦点切换逻辑——多数问题出在事件干扰、DOM 状态不匹配或移动端策略限制上，修复关键在于控制时机和规避默认行为冲突。
focus() 调用无效的四个硬性前提
调用 input.focus() 没反应，大概率卡在以下任一环节：
-
document.activeElement已是目标元素 → 白调，应先判断：if (input && document.activeElement !== input) input.focus() - 元素被
display: none或visibility: hidden包裹 →getComputedStyle(input).display !== 'none'必须为真 - 在非用户手势上下文中调用（如 AJAX 回调、定时器）→ iOS Safari 和部分安卓 WebView 会静默拦截
- 元素未插入 DOM 或 tabindex 设置错误 → 原生
input默认可聚焦；若用div模拟输入框，必须设tabindex="0"，不能是-1
表单提交或 reset 后焦点自动丢失
这是标准行为，不是 bug。调用 form.submit() 或 form.reset() 会清空字段并移除焦点，但你可以主动恢复：
- 对
submit：在event.preventDefault()后手动聚焦，避免页面跳转干扰 - 对
reset：监听reset事件，在回调里加setTimeout(() => input.focus(), 0)—— 因为重置操作同步完成，但 DOM 更新可能有微小延迟 - 使用第三方库（如
react-hook-form）时，查文档确认是否有onReset钩子，别直接操作 DOM
移动端软键盘不弹出或输完就失焦
iOS Safari 和部分 WebView 对软键盘触发极其保守，单纯 focus() 不保证唤起键盘：
- 必须包裹在用户手势中：比如按钮的
onclick、touchend或keydown（Enter 键）回调内调用input.focus() - 输完一个字符就失焦？检查是否绑了
onchange或oninput并在其中执行了 DOM 更新（如重渲染父组件），导致 input 被销毁重建 - 键盘弹出后页面滚动？加参数避免：
input.focus({ preventScroll: true })—— 注意 Safari 15.4+ 才支持该选项 - 动态插入的 input（如模态框内）：不要依赖
autofocus，改用shown.bs.modal（Bootstrap）或useEffect（React）等安全钩子
blur 事件里试图阻止失焦基本无效
event.preventDefault() 在 blur 中不起作用，这是浏览器强制行为。所谓“阻止失焦”本质是失焦后立刻再聚焦回来，但有风险：
- 会造成视觉闪烁，尤其在快速切换 tab 或点击其他 input 时
- 某些场景（如屏幕阅读器、键盘导航）下破坏可访问性
- 若在
blur中异步聚焦（如setTimeout），可能被后续用户操作覆盖 - 真正要解决的是“为什么不该失焦”：比如表单提交时失焦，就该用
event.preventDefault()拦住 submit；比如点击空白区域失焦，就该检查是否误加了pointer-events: none到父容器
最常被忽略的是：移动端软键盘弹出与否，和 focus 是否成功是两个独立判断；而 DOM 是否可见、是否在用户交互流中、是否被框架重渲染——这三者任何一个出问题，都会让焦点逻辑彻底失效。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
