autofocus属性仅在html初始解析时生效，是浏览器一次性触发的原生行为，不支持js动态控制；对动态插入、隐藏、disabled或非可聚焦元素均无效，且同一页面仅首个解析到的元素生效。
autofocus 属性只在 HTML 初始解析时生效
它不是 JS 可控制的“开关”，而是浏览器在解析 HTML 字节流过程中一次性触发的行为。这意味着：autofocus 对动态插入的元素完全无效，哪怕你用 innerHTML 或 appendChild() 插入一个带 autofocus 的 <input>，浏览器也不会重新识别该属性。
常见错误现象包括：Vue/React 组件中写 <input autofocus> 却没聚焦、表单提交后重新渲染新输入框加了 autofocus 但无反应、SPA 路由跳转后焦点丢失。
- 服务端渲染（SSR）或静态 HTML 中的
autofocus最可靠 - 多个元素都写了
autofocus，只有 DOM 中第一个被解析到的生效，其余静默忽略 -
autofocus触发时机早于DOMContentLoaded，甚至可能早于某些内联脚本执行
哪些元素真正支持 autofocus
autofocus 不是所有带 tabindex 的元素都能用，它只对原生可聚焦的表单控件起作用，且有明确类型限制：
- ✅ 支持：
<input type="text">、<input type="email">、<input type="search">、<textarea></textarea>、<button></button>、<select></select> - ❌ 不支持：
<input type="hidden">、<input disabled>、<div contenteditable="true">、<code><div tabindex="0"> <li> <code><input type="password">和<input type="number">理论上支持，但部分 Android WebView 会静默降级 -
<input disabled autofocus>和<input type="hidden" autofocus>表现一致：无焦点、无报错、无提示 - 想实现“先禁用、后启用并聚焦”，必须分两步：
el.disabled = false→el.focus() - 如果元素父容器有
inert属性，或自身display: none/visibility: hidden，autofocus同样不会触发 - WCAG 2.1 明确建议：避免非用户手势触发的自动聚焦，除非上下文非常明确（如模态框打开）
- 屏幕阅读器行为不一致：有的跳过
autofocus元素，有的中断当前播报，导致信息遗漏 - 真机测试比 DevTools 更关键：iOS 上
autofocus“生效”但没弹键盘，大概率是被 Safari 主动拦截了 - 更稳妥的做法是绑定一次用户点击/触摸后调用
.focus()，比如：<button onclick="document.getElementById('q').focus()">开始搜索</button>
注意：autofocus 是布尔属性，写成 <input autofocus> 或 <input autofocus=""> 都合法；写成 _autofocus、data-autofocus、autofocus="true" 全部无效。
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
disabled 属性让 autofocus 彻底失效
disabled 不仅禁用交互，还直接切断元素的可聚焦能力 —— 即使加了 autofocus，浏览器也会跳过它。这不是 bug，而是规范行为：一个 disabled 元素在 DOM 中不参与 Tab 顺序，也不响应任何自动聚焦逻辑。
移动端和无障碍场景下 autofocus 很难如预期工作
iOS Safari 默认抑制页面加载时的 autofocus，尤其在后台切回、iframe 嵌入、或非主文档上下文中。Android Chrome 也在逐步收紧策略，软键盘往往不会自动弹出，即使焦点已落在输入框上。
真正麻烦的不是怎么写 autofocus，而是它“只生效一次”+“无法重试”的刚性限制 —— 页面重载、路由切换、条件渲染后的焦点恢复，全得靠 JS 主动控制，且必须确保元素已挂载、可见、未被禁用。
