autofocus属性仅在HTML初始解析时对首个可聚焦元素生效，静态页面适用；动态渲染、SPA、iOS Safari及模态框中失效，须用JS手动focus()并确保元素已挂载、可见且可聚焦。
autofocus 属性在页面加载时自动聚焦到指定表单元素
只要页面一打开，autofocus 就会让浏览器把光标直接落在目标输入框上，省去用户手动点击或按 Tab 切换的步骤。这对登录页、搜索框、弹窗表单等场景特别实用——但要注意它只对第一个带 autofocus 的可聚焦元素生效，后续的会被忽略。
常见错误是给多个 <input> 都加了 autofocus，结果只有第一个起作用；更隐蔽的问题是，在 SPA（如 React/Vue）中服务端渲染后又由 JS 动态插入表单，此时 autofocus 可能被忽略，因为浏览器已结束初始聚焦逻辑。
-
autofocus是布尔属性，写成autofocus或autofocus="autofocus"效果一样，推荐简写 - 仅支持部分表单控件：
<input>（除type="hidden"）、<textarea>、<select>、<button> - 移动端 Safari 在某些版本中会禁用自动聚焦（尤其弹窗内），需配合
setTimeout+.focus()回退方案
与 JavaScript 的 focus() 方法对比：何时该用哪个
autofocus 是声明式、零 JS 介入的方案，轻量且语义清晰；而 focus() 是命令式，可控性更强但要处理时机问题。比如表单是异步加载的，autofocus 失效，就必须用 JS 主动调用 .focus()。
容易踩的坑是：在 DOM 尚未挂载完成时就调用 input.focus()，导致报错 Cannot read property 'focus' of null。这时候得确保元素存在，或用 requestAnimationFrame 延迟一帧。
立即学习“前端免费学习笔记（深入）”；
- 静态 HTML 表单 → 优先用
autofocus，简洁可靠 - 动态渲染/条件展示的表单 → 放弃
autofocus，改用element.focus()并监听mounted或DOMContentLoaded - 需要兼容 iOS Safari 弹窗聚焦 → 必须用 JS，且建议加
{ preventScroll: true }参数避免意外滚动
无障碍与用户体验的隐性影响
屏幕阅读器会跟随 autofocus 自动朗读当前聚焦元素的标签（<label for>），这是加分项；但如果页面顶部有重要通知或警告，光标直接跳到底部输入框，反而会让视障用户错过关键信息。
另一个常被忽略的点：Chrome 在新标签页中打开含 autofocus 的页面时，焦点可能被浏览器地址栏劫持（尤其用户设置了“新标签页打开时聚焦地址栏”）。这不是代码问题，但会影响实测效果。
- 务必为
autofocus元素提供明确的<label>，否则辅助技术无法正确识别用途 - 不要在模态框（modal）首次显示时依赖
autofocus，因为模态框本身可能还没完成display: block切换，浏览器不会重新触发聚焦逻辑 - 如果表单提交后重置并再次聚焦，不能只靠
autofocus—— 它只在页面加载时生效一次
Vue/React 中的 autofocus 失效原因和绕过方式
框架组件的生命周期和 DOM 渲染时机与原生 HTML 不同。autofocus 在组件挂载前就被解析，但此时元素还没插入文档，浏览器不执行聚焦。React 函数组件里甚至根本不会响应 autofocus 属性（它被当成普通 prop 传给 DOM 元素，但 React 不透传该属性）。
解决方案不是硬加 ref 和 useEffect，而是先确认是否真需要自动聚焦：比如搜索页从首页跳转而来，用户本意就是输入，那聚焦合理；但如果是表单校验失败后回到页面，强行聚焦反而打断用户查看错误提示的流程。
- React 中：用
useRef+useEffect(() => { ref.current?.focus() })，注意加依赖数组防止重复执行 - Vue 3 Composition API：用
onMounted(() => inputRef.value?.focus())，别忘了v-model绑定的ref要指向元素而非值 - SSR 场景下，服务端渲染出
autofocus，但客户端 Hydration 后焦点丢失 —— 这时需在onMounted或useEffect中补一次.focus()
autofocus 看似简单，但时机、上下文、设备差异和辅助功能支持，每一处都容易漏掉。 
