autofocus未生效最可能因页面存在多个autofocus或元素未挂载到DOM；它仅在首次加载时生效，不支持动态添加或条件渲染，且需确保元素可见、可聚焦并兼顾可访问性。
autofocus 属性为什么没生效
常见现象是加了 autofocus 但页面加载后焦点没落到输入框上——最可能的原因是页面里有多个 autofocus，或者元素还没挂载到 DOM 就触发了聚焦（比如在 Vue/React 中用在条件渲染的组件里，初始为 false，之后才显示）。
浏览器只允许一个元素拥有 autofocus，且仅在页面首次加载时生效；后续 JS 修改 autofocus 属性不会触发聚焦。它也不是“自动获取焦点”的实时开关，而是一次性声明。
- 确保整个 HTML 文档中只有一个
autofocus属性（检查隐藏表单、模态框、动态插入的片段） - 不要在
v-if或{show && <input autofocus>}这类条件渲染中直接写autofocus，改用ref+focus()手动控制 - 如果表单在
display: none或visibility: hidden容器里，autofocus会被忽略（元素不可聚焦）
autofocus 在现代框架里怎么替代
React/Vue/Svelte 等框架中，autofocus 常失效，因为 DOM 渲染时机和原生 HTML 不同。这时候得靠 JS 主动调用 focus()，但要注意执行时机。
关键不是“能不能用”，而是“什么时候能安全调用 focus()”。比如 React 的 useEffect、Vue 的 onMounted、Svelte 的 onMount 都是合理位置；但若元素还在 transition 动画中、或父容器尚未 visible，仍会失败。
立即学习“前端免费学习笔记（深入）”；
- React 示例：
useEffect(() => { inputRef.current?.focus(); }, []); - Vue 示例：
onMounted(() => { inputRef.value?.focus(); }); - 避免在
setTimeout(() => el.focus(), 0)这种“投机”写法——它不可靠，尤其在低性能设备或高延迟渲染场景下容易错过
autofocus 和可访问性（a11y）的冲突点
屏幕阅读器用户可能被 autofocus 打断阅读流程，尤其当焦点跳转到页面中部或底部的输入框时。WCAG 明确建议：除非有明确用户意图（如搜索页、登录弹窗），否则避免自动聚焦。
更麻烦的是，某些旧版 iOS Safari 会强制滚动到 autofocus 元素，导致页面错位；Android Chrome 则可能放大输入框遮挡内容。这些行为无法用 CSS 或 JS 拦截。
- 登录页、独立搜索页等「以输入为核心任务」的场景可用
autofocus - 首页、仪表盘、多步骤表单的非首步，禁用
autofocus，改由用户主动点击/Tab 导航 - 如果必须自动聚焦又兼顾 a11y，可在
autofocus同时加aria-live="polite"提示，但不如直接放弃自动聚焦来得稳妥
autofocus 的兼容性和 polyfill 边界
autofocus 在 IE9+、所有现代浏览器都支持，但不支持动态添加（即 JS 创建元素后设 autofocus=true 不生效）。也没有标准 polyfill，因为它的行为依赖浏览器加载阶段，JS 无法模拟那个时机。
有人试图用 document.addEventListener('DOMContentLoaded', ...) 补救，但依然可能早于样式计算或布局完成，导致聚焦后输入框被滚动裁切（尤其在 position: fixed 或 transform 容器里）。
- 不要对
contenteditable元素或textarea外的自定义组件滥用autofocus—— 它们不一定可聚焦，需显式加tabIndex - 服务端渲染（SSR）场景下，
autofocus只在首屏 HTML 有效；CSR 渲染完成后，它已失去意义 - 测试时别只看 Chrome，用 Safari（iOS 模拟器）、Firefox（禁用硬件加速）多验证一次滚动与聚焦是否同步
真正难的不是加个属性，而是判断「此刻该不该聚焦」——用户在哪儿、想干什么、屏幕阅读器是否正在播报、键盘导航是否已开始。这些没法靠 autofocus 自动回答。
