autofocus仅按HTML源码顺序对首个可聚焦元素生效，动态插入或客户端渲染的表单中不触发；iOS Safari仅允许用户手势同步调用focus()。
autofocus 在多表单页面中不会“智能选中当前可见表单”，它只认 HTML 源码顺序，且仅生效一次——所以你看到的焦点乱跳、不聚焦、或聚焦到不该聚焦的输入框，不是 bug，是规范行为。
autofocus 在多表单共存时只对第一个解析元素生效
浏览器在解析 HTML 字符串时扫描 autofocus，一旦遇到第一个可聚焦元素（如未禁用的 <input type="text">），就立即聚焦并停止后续扫描。哪怕你有登录表单、注册表单、搜索框三个都写了 autofocus，只有源码里最靠前的那个会触发，其余静默忽略。
- 常见现象：
<form id="search"><input autofocus></form>在 HTML 顶部，而用户实际打开的是底部的<form id="login"><input autofocus></form>→ 光标永远停在搜索框 - 服务端渲染（SSR）+ 客户端 hydrate 场景下，SSR 输出的
autofocus优先生效，JS 后续挂载的表单里同名属性完全无效 -
<input type="hidden" autofocus>或<input disabled autofocus>不算“可聚焦元素”，会被跳过，但不会让下一个autofocus接替
动态加载表单后 autofocus 完全不触发
通过 fetch 加载 HTML 片段、v-if 切换、innerHTML 插入、或 React useState 控制显示的表单，其内部的 autofocus 属性不会被重新识别——DOM 是 JS 运行时插入的，HTML 解析早已结束。
- 错误写法：
document.getElementById('form-container').innerHTML = '<input autofocus>';→ 属性存在，但无任何效果 - Vue 中
<input v-if="showLogin" autofocus>：组件挂载时 DOM 已存在，但autofocus不会回溯执行 - React 中
<input autoFocus />（注意是autoFocus，JSX 驼峰）只是个 prop，不等于原生行为；它由 React 在componentDidMount或useEffect中模拟，但依然受制于挂载时机和 iOS 手势限制
排查焦点异常的四个必查点
不要只盯着 autofocus 属性是否存在，要验证浏览器是否真的“允许聚焦”：
立即学习“前端免费学习笔记（深入）”；
-
element.isConnected === true：元素必须已挂载进document，不能是 fragment 或未 append 的节点 -
element.offsetParent !== null：排除display: none、visibility: hidden、inert等隐藏/锁定状态 -
element.tabIndex >= 0 && !element.disabled && !element.hasAttribute('inert')：确保可聚焦且未被禁用 -
document.activeElement !== element：避免重复调用干扰用户当前输入，尤其在弹窗快速切换时
iOS Safari 下聚焦失败却不报错
这是最容易被忽略的硬性限制：iOS Safari 会静默拒绝所有非用户手势同步上下文中的 focus() 调用——包括 useEffect、onMounted、setTimeout、甚至 requestAnimationFrame，只要不是直接来自 click/tap/keydown 回调，就大概率失败。
- 正确链路示例：用户点击「打开登录弹窗」按钮 → 按钮
onClick回调中立即调用inputRef.current?.focus() - 错误链路：路由跳转 →
useEffect监听 location 变化 → 触发input.focus()→ iOS 上光标不动、软键盘不弹 - 若需兼容旧版 Safari（focus({ preventScroll: true })，改用
input.scrollIntoView({ block: 'nearest' })配合手动 focus
真正麻烦的从来不是“怎么加 autofocus”，而是“怎么安全地移除它，并用 JS 在对的时间、对的条件下、对的元素上执行一次 focus()”。多表单页面的焦点管理，本质是 DOM 状态 + 用户意图 + 浏览器策略的三重校准，漏掉任一环，光标就可能卡在你想不到的地方。
