autofocus 属性仅对可聚焦的表单元素（input、textarea、select、button）生效，但在 ios safari 等移动端浏览器常被忽略，且存在可访问性与多元素冲突风险，推荐用 javascript 按需聚焦替代。
autofocus 属性确实能让表单元素在页面加载时自动获得焦点，但它的行为远不是“加个属性就完事”——它在不同场景下表现不一，尤其在移动端和辅助技术环境中容易出问题。
autofocus 在哪些元素上能用
它只对可聚焦的表单控件生效：input、textarea、select、button。其他元素（比如 div 或自定义组件）即使加了也不会触发聚焦。
-
input类型不限，type="text"、type="search"、type="email"都支持；但type="hidden"不行（不可聚焦） -
textarea和select直接加autofocus即可，无需额外配置 -
button加上后会获得焦点，但注意：它不会自动触发点击，只是键盘可操作起点 - Vue/React 等框架中，若组件封装了原生元素（如
<b-form-input autofocus></b-form-input>），需确认该组件透传了autofocus属性，否则无效
iOS Safari 和部分安卓浏览器会忽略 autofocus
这是最常被踩的坑：页面一打开，光标没动，键盘也没弹——尤其在 iOS Safari 中，autofocus 几乎总是被静默忽略，因为浏览器主动阻止非用户手势触发的键盘弹出。
- 原因不是 bug，而是策略：防止页面加载时意外遮挡内容或打断浏览流
- Android Chrome 通常支持，但某些定制 ROM 或 WebView（如微信内置浏览器）也可能禁用
- 如果元素初始被
display: none、visibility: hidden包裹，或位于未激活的 TabPane / Modal 中，autofocus会失效（DOM 存在但不可聚焦） - 解决方案不是放弃，而是补 JS：在
DOMContentLoaded后手动调用.focus()，并加一层防护
document.addEventListener('DOMContentLoaded', () => {
const el = document.querySelector('input[name="q"][autofocus]');
if (el && document.activeElement !== el) {
el.focus();
}
});
多个 autofocus 元素的行为不可靠
规范没定义多 autofocus 的处理方式，浏览器实现五花八门：Chrome 通常取第一个，Firefox 可能取最后一个，Safari 可能全忽略。
- 即使只有一个生效，也意味着你无法通过 HTML 控制“条件聚焦”（比如根据 URL 参数决定聚焦哪个字段）
- 更隐蔽的问题是：如果服务端渲染时动态插入了带
autofocus的新字段（如表单校验失败后重绘），可能和原有字段冲突 - 真正安全的做法是：HTML 中不写任何
autofocus，统一用 JS 按需聚焦；或者确保整个页面生命周期内，仅一个元素带该属性且位置稳定 - 特别注意 SSR + hydration 场景：Vue/React 服务端渲染时若写了
autofocus，客户端 Hydration 后可能因 DOM 重建导致聚焦丢失
聚焦时机与可访问性风险
autofocus 在 DOM 解析阶段就被识别，比 DOMContentLoaded 更早，但它不触发 focus 事件（部分旧版浏览器除外），这意味着依赖该事件的逻辑（如高亮边框、滚动到视口）可能不执行。
- 屏幕阅读器会按
autofocus移动焦点，但可能跳过前面的<h1></h1>或说明文案，造成信息断层 - 如果聚焦的是密码框（
<input type="password">），对首次访问用户很不友好——他们还没看清页面结构，光标已落在敏感字段 - 软键盘在移动端自动弹出，可能遮住标题、按钮或错误提示，尤其在小屏设备上
- 替代思路：对关键页（如独立搜索页）用
autofocus；对复杂页（如带导航栏+多区块的仪表盘）改用 JS，在用户明显进入表单区域后再聚焦
真正难的不是让光标动起来，而是判断“此刻该不该动”。autofocus 是个开关，但开或关的决策，得基于用户当前上下文、设备能力、页面结构和辅助技术需求——这些没法靠一个布尔属性自动推导。
