autofocus属性仅在html初始解析时对首个符合条件的可聚焦元素生效，动态插入、spa、模态框及ios safari中均失效，应改用js手动focus()并校验元素可见性、可聚焦性及用户手势上下文。
autofocus 属性在绝大多数实际场景中都不可靠，尤其是涉及动态渲染、SPA、模态框或 iOS Safari 时——它只在原始 HTML 解析阶段起一次作用，之后完全失效。
autofocus 只在初始 HTML 解析时生效，不是 JS 可控的开关
浏览器只在解析 DOM 树的那一刻扫描 autofocus，后续任何 JS 操作（如 innerHTML 替换、appendChild()、Vue/React 组件挂载）都不会触发它。这意味着：
-
document.getElementById('form').innerHTML = '<input type="text" autofocus>'→ 焦点不会出现 -
input.autofocus = true或input.setAttribute('autofocus', '')→ 完全无效 - 服务端渲染（SSR）后 hydration 的
<input autofocus>→ 不会聚焦，因为 DOM 已存在 - 页面从后台标签页切回、或 iframe 内加载 → Safari 会静默丢弃该行为
哪些元素真正支持 autofocus？类型和状态都有限制
不是所有 input 都能用 autofocus，必须同时满足：可聚焦 + 可交互 + 未被禁用。常见情况如下：
Html To Pdf
下载
使用 Puppeteer + Chrome 将 HTML 渲染为中文 PDF，自动处理图表等待、Tab 展开、动画、测高、白边消除、防分页，适用于看板、报表、网页和交互图表转 PDF。
- ✅ 稳定支持：
<input type="text">、<input type="search">、<input type="email">、<textarea></textarea> - ⚠️ 有条件支持：
<button></button>（Chrome/Firefox 行为一致，Safari 偶尔跳过）、<select></select>（Firefox 和旧版 Safari 明确不支持） - ❌ 不支持：
<input type="hidden">、<input type="checkbox">、<input type="file">、<input disabled>、<div tabindex="0"> <li>隐藏即失效：<code>display: none、visibility: hidden、inert或tabindex="-1"包裹的元素，autofocus直接被跳过 - 首页
<input autofocus>→ 键盘大概率不弹，焦点可能设了但不可见 - 模态框
show()后的autofocus→ 失效，除非聚焦调用包裹在onclick或ontouchend回调里 -
.focus()在用户手势后调用才安全，例如：button.addEventListener('click', () => input.focus()) - 即使聚焦成功，
.focus({ preventScroll: true })才能避免页面滚动，而autofocus没这个能力 - SPA 中优先用框架钩子：
useEffect(() => ref.current?.focus(), [])（React）、onMounted(() => inputRef.value?.focus())（Vue 3） - 原生 JS 场景下监听
DOMContentLoaded，而非window.onload（后者等资源，太晚） - 务必检查
document.activeElement !== input，避免覆盖用户已有的输入操作 - SSR 环境必须加
if (typeof window !== 'undefined')，否则服务端报错 -
form.reset()后焦点不会恢复，必须手动补焦 —— 这一点极易被忽略
移动端（尤其 iOS Safari）基本不能依赖 autofocus
iOS Safari 主动限制非用户手势触发的自动聚焦，目的是防止软键盘意外弹出遮挡内容。结果是：
比 autofocus 更靠谱的做法：JS 显式 focus() 并加防护逻辑
只要不是纯静态页面，都应该放弃 autofocus，改用 JS 控制。关键不是“能不能调”，而是“什么时候调、要不要调”：
真正麻烦的从来不是怎么写 autofocus，而是它失效时你根本收不到任何提示；更隐蔽的问题是：它在桌面 Chrome 里好好的，一上真机就哑火，而你直到测试阶段才发现键盘没弹出来。
