autofocus 在 Vue 或 React 的异步组件中无法生效，根本原因在于浏览器只在 HTML 初次解析时扫描该属性。而组件挂载、SSR 水合（hydration）以及 v-if 条件渲染都发生在 DOM 构建完毕之后——此时 autofocus 已成为“死属性”，浏览器不会二次识别。解决方案是放弃 autofocus，改用手动调用 focus() 方法，并额外校验元素可见性、当前焦点状态、用户手势上下文以及滚动行为。
先给出结论：autofocus 在异步组件中失效，这不是框架的 bug，而是浏览器规范决定的。无论你使用 Vue 还是 React，思路完全一致——放弃 autofocus 属性，手动调用 focus() 方法，并且必须避开四个常见陷阱。
接下来详细分析失效原因，以及正确的实现方式。
autofocus 在 Vue/React 异步组件中为何完全不生效
根本原因：浏览器只在 HTML 初始解析阶段识别 autofocus 属性，而 Vue/React 的组件挂载、SSR 水合、v-if 条件渲染都发生在 DOM 构建完成之后——此时 autofocus 变成“死属性”，无论元素上是否真实存在该属性，浏览器都不会重新触发聚焦。
常见现象： 写在 Vue 模板中，但组件 onMounted 后 document.activeElement 仍然是 body；在 React 的 useEffect 里查看 ref.current 发现元素存在，但光标并未自动定位。
- 这不是框架的 bug，而是浏览器规范：HTML 解析是一次性过程，不可重放
- 即使 SSR 输出带有
autofocus也无用——水合只是复用现有 DOM 节点，不会触发二次解析 - 对已挂载的元素执行
el.setAttribute('autofocus', '')或el.autofocus = true完全无效
手动 focus() 调用必须绕开的四个坑
直接写 input.focus() 很容易失败，尤其在移动端或复杂布局下。关键不是“要不要调用”，而是“什么时候调用、如何判断、怎么防御”。
- 先检查是否已被聚焦：
if (input && document.activeElement !== input) input.focus()，否则可能打断用户正在进行的输入操作 - 确保元素可见：
getComputedStyle(input).display !== 'none' && getComputedStyle(input).visibility === 'visible' - iOS Safari 强制要求用户手势上下文：不能在
useEffect或onMounted里直接调用，必须包裹在click、keydown等事件回调中 - 避免软键盘触发意外滚动：使用
input.focus({ preventScroll: true })（注意 Safari 15.4+ 才支持，旧版本需配合scrollIntoView({ block: 'nearest' })）
React/Vue 中安全聚焦的钩子写法
框架的生命周期钩子并不等于“元素已就绪”，必须叠加 DOM 更新确认机制。
- React：
useEffect(() => { if (ref.current && document.activeElement !== ref.current) { ref.current.focus({ preventScroll: true }); } }, [])——但要确保ref绑定的是最终渲染的节点，而不是v-if条件分支外的空容器 - Vue：
onMounted(() => { nextTick(() => { if (inputRef.value && document.activeElement !== inputRef.value) { inputRef.value.focus({ preventScroll: true }); } }); })——nextTick比setTimeout(() => ..., 0)更可靠，能确保v-if/v-for渲染彻底完成 - 原生 JS 异步插入后：
el.insertAdjacentHTML('beforeend', ''); const input = el.querySelector('input[name="q"]'); requestAnimationFrame(() => input?.focus({ preventScroll: true }))——requestAnimationFrame比setTimeout更精准，且能避开与原生autofocus的冲突
焦点陷阱和无障碍的隐藏风险
自动聚焦不只是技术问题，更是交互责任。一个处理不当的 focus() 可能让用户迷失在页面中，尤其对屏幕阅读器用户影响更大。
- 模态框打开后聚焦第一个可操作元素是合理场景，但如果该元素被
display: none的父容器包裹，focus()会静默失败，且 VoiceOver 可能跳过整个区域 - 登录页自动聚焦密码框违反 WCAG 原则——用户还没看到标题和说明就进入输入状态，信息流被截断
- 顶部 banner 设置了
scroll-margin-top但未正确使用，focus()触发滚动后输入框被 header 遮挡，iOS 下更难手动修正 - 多个异步加载模块都试图聚焦自己区域的第一个
input，导致焦点在不同模块间来回跳转，形成焦点陷阱
最麻烦的不是代码写错，而是“看起来能用”——它在 Chrome 桌面端跑通了，但在 iOS Safari 里静默失效，在 VoiceOver 下跳过关键内容，在用户连续点击两次按钮后突然抢走焦点。这些都依赖 document.activeElement 实时校验和手势上下文兜底，而不是靠一次 focus() 调用就能万事大吉。
