autofocus属性不保证元素获得焦点，仅在页面首次加载且无其他脚本调用focus()时尝试触发，多实例仅首例生效，dom未就绪时被忽略；ios safari默认禁用，需用户手势兜底；与js focus()冲突易致光标跳动或键盘重复弹出；影响可访问性，需谨慎用于主操作入口并确保语义与焦点管理。

autofocus 属性是否保证元素获得焦点

不保证。浏览器只在页面首次加载、且没有其他脚本主动调用 focus() 时，才尝试触发 autofocus。如果页面中有多个 autofocus，只有第一个有效；如果 DOM 尚未就绪（比如写在 里或异步加载的模板中），它会被忽略。

移动端 Safari 和 Chrome 的 autofocus 行为差异

iOS Safari 默认禁用 autofocus（无论是否用户交互触发），除非焦点请求来自明确的用户手势（如点击事件）。Android Chrome 大多支持，但部分定制 ROM 或旧版本会静默忽略。这意味着：即使写了 <input autofocus>，iOS 上几乎总是没反应。

html-deploy

使用 htmlcode.fun 将 HTML 内容或文件部署到网页，适用于用户要求“部署到网页”“托管此 HTML”“生成此前端...的实时链接”等场景。

下载

• 真机测试必须覆盖 iOS 实际环境，模拟器不可靠
• 若需强制聚焦，得用 JS + 用户事件兜底，例如监听 click 或 touchstart 后调用 input.focus()
• autofocus 在 WebView 中行为更不稳定，尤其 Cordova 或 React Native 的 Web 容器

autofocus 与 JavaScript focus() 冲突的典型表现

常见错误是同时写 <input autofocus> 并在 DOMContentLoaded 里调用 input.focus() —— 这会导致焦点被覆盖、光标跳动，甚至在某些 Android 浏览器中触发软键盘两次。

• 优先用 autofocus 做声明式默认行为，避免后续 JS 主动调用 focus()
• 如果必须用 JS 控制，就彻底移除 autofocus 属性，改用 setTimeout(() => input.focus(), 0) 或 requestAnimationFrame 确保 DOM 就绪
• 注意 focus() 可能抛出异常（如元素不可见、display: none、visibility: hidden），建议加 try/catch

autofocus 对可访问性和屏幕阅读器的影响

它确实会被 VoiceOver、TalkBack 识别为“初始焦点”，但若焦点落在非语义化容器（如 <div contenteditable>）或缺少 <code>aria-label 的输入框上，会破坏导航流。更麻烦的是：自动聚焦可能中断屏幕阅读器正在播报的页面标题。

• 仅对主操作入口（如搜索框、登录表单首字段）使用 autofocus
• 确保该元素有清晰的视觉焦点样式（:focus-visible 或 :focus）
• 避免在模态框打开时依赖 autofocus，应配合 inert 或 aria-hidden 管理焦点锁

实际项目里最容易被忽略的，是 autofocus 在 iOS 上的完全失效和焦点管理与可访问性的耦合——它不是“写上就生效”的便利属性，而是需要按平台、上下文、辅助技术三重校验的交互契约。