autofocus 属性在现代 Web 开发中基本不可靠，应改用 JavaScript 在 DOM 就绪后调用 .focus()；它仅在 HTML 初始解析时生效，对动态插入、SPA 路由切换、模态框显示等场景无效，且 iOS Safari 会静默忽略。

autofocus 属性在现代 Web 开发中基本不可靠，尤其在移动端和 SPA 场景下；真正可用的方案是删掉 HTML 中的 autofocus，改用 JavaScript 在 DOM 就绪后调用 .focus()。

autofocus 只在页面首次解析时生效，动态插入或路由切换后完全无效

浏览器只在 HTML 初始解析阶段处理 autofocus，一旦 DOM 加载完成，它就“冻结”了。这意味着：

• Vue/React 组件挂载后渲染的 不会聚焦 —— 因为 DOM 是 JS 插入的，不是浏览器原生解析的
• 模态框（modal）初始 display: none，显示后再加 autofocus 属性也无反应
• SPA 路由跳转到新页面，哪怕模板里写了 autofocus，也不会触发 —— 页面没刷新，浏览器不重新解析
• 服务端渲染失败后重绘表单，新插入的带 autofocus 的 会被静默忽略

哪些元素支持 autofocus？类型限制很明确

不是所有 都能用 autofocus，它只对可交互、可获得焦点的控件有效：

• ✅ 支持：、、、、、、
• ❌ 不支持：、、、（安全策略）、（行为不一致）
• ⚠️ 注意：
  无效，必须同时设 tabindex="0" 才可能聚焦

  iOS Safari 会静默忽略 autofocus，且不报错

  iOS Safari 对非用户手势触发的聚焦有严格限制，这是策略，不是 bug：

  • 首页 → 键盘大概率不弹出
  • 模态框通过 show() 显示后直接调用 input.focus() → 若不在点击/触摸回调内，仍可能失败
  • 即使聚焦成功，软键盘弹出会遮挡内容，尤其在小屏或固定定位元素附近
  • Android Chrome 多数支持，但微信 WebView、某些定制 ROM 常禁用

  补救方式：把 .focus() 包在用户事件回调中，比如 button.onclick = () => input.focus()，或用 requestAnimationFrame 延迟一帧确保渲染完成。

  

  HTML Text Extract

  从HTML页面（URL、文件或标准输入）中提取主体内容文本，去除导航、页脚、广告和模板文本。可直接传递给readability_check或其他文本工具。

  下载

  多个 autofocus 元素的行为不可预测，别指望控制顺序

  HTML 规范没定义多 autofocus 的优先级，浏览器实现各异：

  • Chrome：取 DOM 中第一个
  • Firefox：可能取最后一个
  • Safari：可能全忽略
  • 更麻烦的是：服务端根据校验结果动态插入新字段并带 autofocus，可能和原有字段冲突，导致焦点跳变或丢失

  真正可控的做法是：HTML 中一个 autofocus 都不写，统一用 JS 控制。例如 React 用 useRef + useEffect(() => { ref.current?.focus() }, [])；Vue 3 用 onMounted(() => inputRef.value?.focus())。记得加可选链（?.focus()），避免 SSR 渲染时 ref.current 为 null 报错。

  最易被忽略的一点：autofocus 和 JS 的 .focus() 混用会导致焦点反复抢夺，iOS 上甚至可能让键盘弹起又收起。如果你已经删掉了 HTML 中的 autofocus，却还在某个 setTimeout 或 componentDidMount 里手动 .focus()，请检查是否重复触发 —— 真实场景中，一次精准的、时机恰当的 .focus() 就够了。