autofocus 属性在 HTML 解析阶段即生效，早于 DOMContentLoaded；其正确使用需满足唯一性、初始存在、可见、可聚焦、支持聚焦五条件，并应在明确用户意图的场景（如登录页、搜索结果页）谨慎启用，避免损害可访问性与移动端体验。
autofocus 属性本身不依赖 DOM 就绪事件——它由浏览器在 HTML 解析阶段自动识别并执行，比 DOMContentLoaded 还早。所谓“配合 DOM 准备就绪事件”，其实是常见误解；真正需要配合的，是确保元素已挂载、可见、可聚焦，且聚焦行为符合用户预期。最佳首屏交互引导的关键不在“怎么加 autofocus”，而在于“该不该加、加在哪、失败了怎么办”。
只在明确用户意图的场景启用 autofocus
首页 Banner、仪表盘、内容列表页等非表单主导页面，不应自动聚焦输入框。autofocus 合理的使用场景非常有限：
- 独立登录页或注册页（URL 路径如
/login或/signup） - 搜索结果页顶部的搜索框（用户刚提交搜索，返回结果后应继续输入）
- 模态框（Modal）中唯一且必填的输入字段（如“新建标签名”弹窗）
- 空状态页的创建入口（如“暂无笔记，点击新建”后的输入框）
确保 autofocus 实际生效的硬性条件
即使写了 autofocus，也常失效。必须同时满足以下五点：
- 整个 HTML 文档中仅存在一个
autofocus属性（检查隐藏表单、后台加载的组件、服务端渲染的冗余片段） - 目标元素在页面初始 HTML 中就存在（不能靠 JS 动态插入，也不能用
v-if/{show && <input autofocus>}等条件渲染包裹） - 元素未被隐藏：
display: none、visibility: hidden、opacity: 0（哪怕只是 CSS transition 的起始帧）都会导致忽略 - 元素未禁用：
disabled或readonly属性存在时，autofocus 被静默跳过 - 元素支持聚焦：仅限
<input>（除type="hidden"）、<textarea></textarea>、<button></button>、<select></select>、<iframe></iframe>
现代框架中更可靠的替代方案
在 Vue、React、Svelte 等单页应用中，autofocus 失效是常态。此时应放弃声明式属性，改用命令式聚焦，并严格控制时机：
- Vue 3：在
onMounted中调用inputRef.value?.focus()，并确认父容器已display: block且无inert属性 - React：用
useEffect(() => { inputRef.current?.focus(); }, [])，避免setTimeout(..., 0)这类不可靠兜底 - Svelte：在
onMount中调用inputElement.focus()，若元素在动画后出现，需监听transitionend再聚焦 - 通用增强：聚焦前检查
el.offsetParent !== null && el.offsetWidth > 0 && el.offsetHeight > 0，避免对不可见元素调用 focus()
兼顾可访问性与移动端体验
自动聚焦不是无障碍友好功能，需主动规避风险：
- 屏幕阅读器用户可能刚进入页面，正通过标题或导航了解上下文，突然焦点跳转会打断流程。WCAG 建议：除非用户已有明确操作意图（如从搜索按钮跳转而来），否则禁用 autofocus
- iOS Safari 会强制滚动到 autofocus 元素，可能遮挡顶部导航栏；Android Chrome 可能立即唤出键盘，盖住关键信息。这些行为无法拦截，只能回避
- 若必须聚焦，建议搭配
scrollIntoView({ block: 'nearest', inline: 'nearest' })控制滚动行为，或用preventScroll: true抑制默认滚动（注意兼容性） - 对移动端，可结合
matchMedia('(pointer: coarse)')判断是否为触控设备，触控设备上默认禁用 autofocus，改由用户首次点击触发
