autofocus在弹窗中常失效，因其仅在HTML解析时生效，而隐藏态弹窗元素未进入渲染流；必须在弹窗显示后、元素可见且可聚焦时手动调用focus()，并确保在用户手势同步上下文中执行，尤其需兼容iOS Safari限制。
autofocus 在弹窗中为什么经常失效
因为 autofocus 是页面加载时触发的，而弹窗（比如用 display: none 或 visibility: hidden 控制）初始状态下元素不在渲染流中，浏览器会忽略它的 autofocus 属性。即使你给弹窗里的 <button autofocus> 加了属性，只要弹窗没显示，它就压根不会聚焦。
用 JavaScript 手动 focus() 更可靠
弹窗显示后立刻调用 .focus() 是最稳妥的做法，尤其配合现代框架或原生 DOM 操作。注意时机必须是元素已挂载且可见：
- 确保弹窗容器已添加到 DOM 且
display不为none（可用offsetParent !== null或getComputedStyle(el).display !== 'none'判断） - 避免在
setTimeout(() => {}, 0)里盲目调用——某些 CSS 动画或 transition 还没完成，元素可能仍不可聚焦 - 推荐用
requestAnimationFrame延迟到下一帧，兼顾性能和可靠性：showModal();<br>requestAnimationFrame(() => {<br> document.getElementById('confirm-btn').focus();<br>});
focus() 被阻止的常见原因和绕过方式
有些浏览器（特别是 Safari）在模态框首次显示时会阻止自动聚焦，尤其是当焦点目标不是可 tab 键访问的元素（如 div），或弹窗由非用户手势（如 setTimeout）触发。解决办法：
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 确认按钮有
tabindex="0"且未被disabled或hidden属性影响 - 聚焦操作必须发生在用户交互（如
click、keydown）的同步回调内，否则会被视为“非用户发起”，Safari 直接拒绝 - 如果弹窗由异步逻辑打开（比如 API 返回后），需缓存用户手势上下文，例如在点击按钮时记录
event，之后在响应中复用event.target.focus()的合法性
别忘了可访问性配套处理
只聚焦按钮不够，屏幕阅读器需要知道弹窗是活跃模态区域。必须配合同步设置：
立即学习“前端免费学习笔记（深入）”；
- 弹窗根元素加
role="dialog"和aria-modal="true" - 用
aria-labelledby指向标题元素（确保该元素存在且非空） - 聚焦后，按
Tab应只在弹窗内循环（需手动 trap focus，autofocus本身不提供这个能力）
真正麻烦的从来不是让按钮获得焦点，而是让整个焦点流可控、可预期、不逃逸——这点容易被跳过，但一上线就被无障碍测试卡住。
