autofocus仅在HTML初始解析时生效，动态插入无效；仅对原生可聚焦元素（如input、textarea等）起作用，且iOS Safari和屏幕阅读器存在兼容限制。
autofocus 只在 HTML 初始解析时生效，动态插入无效
浏览器只在页面首次加载、HTML 文本被解析成 DOM 的那一瞬间检查 autofocus 属性。这意味着：
- 用
innerHTML、appendChild()或框架（如 React/Vue）渲染后才出现的元素，即使带autofocus，也完全不会触发聚焦 - 服务端渲染（SSR）后客户端 hydrate 阶段，
autofocus已“过期”，不会重试 -
setAttribute('autofocus', '')或el.autofocus = true这类 JS 操作对已挂载元素无效 - 唯一可靠场景：纯静态 HTML 或 SSR 输出中，目标元素从一开始就在 DOM 树里，且未被
display: none、inert或tabindex="-1"阻断
哪些元素真正响应 autofocus？
autofocus 不是万能开关，它只对「原生可聚焦且处于可用状态」的元素起作用：
- 支持的元素：
input（type不能是hidden、disabled或readonly）、textarea、select、button -
contenteditable="true"的div不认autofocus，必须手动调用.focus() -
div或span加了autofocus但没设tabindex="0"，等于白写 - 多个元素都写了
autofocus，浏览器只聚焦 DOM 中第一个被解析到的，其余被静默忽略
移动端 Safari 和无障碍体验的现实约束
iOS Safari 几乎无视 autofocus，这不是 bug，而是明确的设计限制；同时，自动聚焦对屏幕阅读器用户可能造成信息流中断：
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- iOS Safari 在页面自动加载、iframe 内、或后台切前台时，会直接跳过
autofocus，必须搭配用户手势（如点击按钮）后调用.focus()才能唤起键盘 - 屏幕阅读器（如 VoiceOver）可能在播报完
<h1>前就跳到输入框，导致用户错过关键上下文 - WCAG 不禁止
autofocus，但要求它不能打断已有操作流——比如登录页自动聚焦密码框，就违反「用户控制焦点」原则 - 若页面顶部有 banner 或导航栏，
autofocus可能触发意外滚动，需配合scroll-margin-top调整定位
该用 autofocus 还是 .focus()？看场景
声明式 autofocus 简单，但可控性差；命令式 .focus() 灵活，但容易掉坑：
立即学习“前端免费学习笔记（深入）”；
- 适合
autofocus的场景：独立登录页、搜索结果页顶部搜索框、模态框（modal）首次打开——这些场景意图明确、无干扰、非动态生成 - 必须用
.focus()的场景：SPA 路由切换后聚焦、条件渲染组件挂载后、表单提交失败重置焦点、iOS 兼容兜底 - 调用
.focus()前务必检查：if (el && document.activeElement !== el) el.focus()，避免覆盖用户当前输入 - 注意时机：React 用
useEffect(() => { ref.current?.focus() }, [])；Vue 用onMounted(() => inputRef.value?.focus())；纯 JS 推荐requestAnimationFrame(() => el.focus())而非setTimeout
autofocus 的“一次性”本质——它不响应重绘、不响应条件变化、不响应用户交互后的二次需求。只要页面逻辑稍复杂，就得切到 JS 控制，别指望它反复工作。 
