autofocus 属性有时不生效，主要因页面加载时机、浏览器策略（如首次标签页静音抑制）、DOM 动态插入、父容器隐藏（display: none）或 SPA 路由切换导致；应优先用 JS .focus() 替代，并注意光标位置与输入法兼容性。
autofocus 属性为什么有时不生效
直接加 autofocus 却没聚焦？常见原因不是写法错，而是页面加载时机或浏览器策略干预。比如在模态框（display: none）里写的输入框，即使带 autofocus 也不会触发；或者页面用 document.write() 动态重写、或 JS 阻塞了初始渲染，都会让浏览器跳过 autofocus 行为。
更隐蔽的是：Chrome/Edge 在用户未与页面交互前（如首次打开标签页），对自动聚焦音频/表单控件有静音+抑制策略，尤其当页面含 <audio autoplay> 或弹窗逻辑时，autofocus 可能被静默忽略。
- 确保目标
<input>在 HTML 初始解析时就存在于 DOM 中（不要靠 JS 动态插入后补autofocus） - 避免父容器使用
display: none或visibility: hidden—— 改用opacity: 0+pointer-events: none更安全 - 若必须动态显示（如登录弹窗），改用 JS 显式调用
.focus()，并在setTimeout或requestAnimationFrame中延迟执行
autofocus 和 JavaScript focus() 的关键区别
autofocus 是 HTML 原生属性，仅在页面首次加载时起作用，且只对一个元素生效（多个 autofocus 时，浏览器取第一个有效元素）；而 .focus() 是 JS 方法，可随时调用、可重复触发、支持条件判断和错误处理。
例如登录页中，如果上一次提交失败，服务端返回错误并保留表单，此时希望焦点回到 email 输入框 —— autofocus 完全无能为力，必须用 JS：
立即学习“前端免费学习笔记（深入）”；
if (document.getElementById('email-error')) {
setTimeout(() => document.getElementById('email').focus(), 0);
}
-
autofocus不会触发focus事件，JS 监听不到；.focus()会正常触发 -
.focus()可传选项{ preventScroll: true }避免页面意外滚动，autofocus无此控制 - 移动端 Safari 对
autofocus支持极弱（iOS 15.4+ 才部分放开），但.focus()配合用户手势（如点击按钮）基本都可用
多页面场景下 autofocus 的兼容性陷阱
单页应用（SPA）中，路由切换后新组件挂载，autofocus 属性不会重新生效 —— 因为这不是“页面加载”，只是 DOM 更新。很多人误以为加了属性就能自动聚焦，结果在 React/Vue 组件里反复失效。
真实情况是：Vue 的 v-focus 指令、React 的 useRef + useEffect，底层都是在 mounted 或 componentDidMount 后手动调用 .focus()。
- Next.js App Router 中，
autofocus在客户端组件（'use client'）首次渲染时有效，但导航到同一路由的其他参数页时无效 - Nuxt 3 的
onMounted是更可靠的时机点，而非依赖 HTML 属性 - 若需 SSR 兼容，
autofocus仍建议保留（利于 SEO 和初始体验），但 JS fallback 必须存在
聚焦后光标位置与输入法状态的实际影响
加了 autofocus 后光标默认在开头，但用户可能期望在末尾（如编辑已有内容）；另外中文输入法在自动聚焦瞬间常处于“未激活”状态，导致首次按键不出字 —— 这不是 bug，是浏览器为防滥用做的限制。
解决方式不是禁用 autofocus，而是微调行为：
- 用
.setSelectionRange(input.value.length, input.value.length)把光标移到末尾（需在.focus()后调用） - 对中文输入场景，可监听
input事件，首次触发后再允许逻辑执行，或增加compositionstart判断 - 避免在
autofocus元素上同时设value=""和placeholder，某些安卓 WebView 会因 placeholder 渲染延迟导致聚焦异常
真正麻烦的从来不是怎么加 autofocus，而是它生效之后——光标在哪、输入法是否就绪、用户是否真的需要此刻聚焦。这些细节不处理，自动聚焦反而变成干扰。
