autofocus在多个dialog中仅对首个解析的可聚焦元素生效，后续dialog需手动调用focus()并确保时机正确、元素可聚焦，尤其iOS Safari要求聚焦必须在用户手势同步上下文中执行。
autofocus在多个dialog同时存在时只生效第一个
浏览器规范明确：整个文档中，autofocus 属性仅对**首个解析到的可聚焦元素**起作用。哪怕你写了十个 <dialog><input autofocus></dialog>，只有第一个 dialog 里那个 input 有机会被聚焦，其余全部静默忽略——这不是 bug，是标准行为。
常见错误现象：dialog A 打开后聚焦正常，再打开 dialog B（A 仍 open），B 里的 autofocus 完全没反应；或者服务端渲染时预置了多个带 autofocus 的弹窗模板，结果只有最上面那个生效。
- 别指望靠 HTML 层面“多写几个
autofocus”来覆盖不同场景 - 如果弹窗是条件渲染（如
v-if或{show && <dialog>...</dialog>}），初始未挂载的元素即使带autofocus也无效 -
dialog.showModal()不会触发任何autofocus重评估，它只是把已存在的 DOM 提升为模态层
多个弹窗嵌套或快速切换时 focus() 调用时机错乱
手动调用 element.focus() 是唯一可靠路径，但在多弹窗场景下极易踩坑：焦点可能落在旧弹窗、被遮挡的输入框、甚至背景页面上。关键不是“要不要调”，而是“什么时候调、调哪个、是否能调”。
典型失效链路：弹窗 B 在 A 还没完全关闭时就 show，JS 立即执行 inputB.focus() → 此时 B 的 DOM 节点可能还在 transition 动画中、父容器 opacity: 0 或 visibility: hidden、或被 inert 属性锁住 —— focus() 静默失败，且不报错。
立即学习“前端免费学习笔记（深入）”；
- 推荐用
dialog.addEventListener('focusin', handler, { once: true })替代setTimeout或useEffect初始调用，确保焦点事件真正进入弹窗上下文后再聚焦目标元素 - 必须检查元素是否满足可聚焦前提：
disabled属性要移除，tabindex值不能是-1（除非你显式控制），且父级不能有inert - 若弹窗支持键盘关闭（如 Esc），需在关闭回调里手动清除焦点，避免焦点残留导致 Tab 键跳转异常
iOS Safari 下多弹窗自动聚焦几乎必然失败
在 iOS Safari 中，focus() 必须发生在用户手势（click/tap/keydown）同步上下文中，否则直接静默拒绝。这意味着：哪怕你在 dialog.showModal() 后立刻 requestAnimationFrame(() => input.focus())，只要这个调用不是由用户点击按钮直接触发的，99% 失败。
更麻烦的是，如果弹窗是通过路由跳转或状态变更间接打开（比如点击菜单项 → 触发 state change → 显示 dialog），整个链路脱离了原始手势上下文，focus() 就成了摆设。
- 唯一稳妥方案：把弹窗打开和聚焦绑定在同一用户事件里，例如
<button onclick="openDialogAndFocus()">，并在该函数内同步调用input.focus() - 不要依赖
onMounted或useEffect，它们在 iOS Safari 中无法继承手势上下文 - 若必须异步打开（如 API 返回后显示提示弹窗），考虑加一层轻量级确认按钮：“确定” → 点击后才聚焦输入框，把焦点控制权交还给用户
焦点管理与屏幕阅读器的隐性冲突
多个弹窗叠加时，autofocus 或误用的 focus() 会严重破坏辅助技术流：屏幕阅读器可能从中间弹窗开始朗读，跳过顶部声明、遗漏关闭按钮，甚至把焦点卡在不可见区域。WCAG 要求模态框必须将焦点限制在内部，且首次打开时焦点应落在逻辑起点（通常是第一个可操作控件）。
容易被忽略的事实：一个弹窗里写了 autofocus，另一个用 JS 调用了 focus()，两者无序竞争，最终焦点位置不可预测。这对键盘用户和屏幕阅读器用户都是灾难。
- 每个弹窗应有唯一、明确的焦点入口点，且该点必须是用户意图操作的第一个控件（如搜索框、确认按钮）
- 禁止在非核心任务弹窗（如通知、成功提示）中使用自动聚焦
- 用
aria-modal="true"+inert或aria-hidden="true"主动管理背景内容的可访问性，避免焦点逃逸
