原生 不支持多级嵌套，必须为 的直接子元素，否则浏览器会将其提升至 顶层，导致模态行为异常、焦点错乱；替代方案是单个 动态切换内容，或改用支持嵌套的自定义组件/库。
dialog 标签不支持合法的多级嵌套
HTML 原生 <dialog></dialog> 元素在规范中明确禁止嵌套使用——即一个 <dialog></dialog> 内部不能再放另一个 <dialog></dialog>。浏览器（Chrome、Edge、Firefox）遇到嵌套时，会自动将内层 <dialog></dialog> “提升”到 顶层，破坏 DOM 层级关系，导致 showModal() 行为异常、close() 失效、焦点管理错乱。
这不是兼容性问题，而是标准行为。W3C HTML Living Standard 明确指出：<dialog></dialog> 必须是 的直接子元素，否则视为“不规范（non-conforming）”。即使你强行写成嵌套结构，DevTools 里看到的 DOM 也早已被重排。
为什么不能靠 CSS z-index 模拟嵌套
有人尝试用 position: fixed + 高 z-index 手动叠加多个 <dialog></dialog>，看似“多层”，实则存在三个硬伤：
- 每个
<dialog></dialog>独立调用showModal()时，会各自拦截整个页面的焦点和键盘事件（比如Escape），导致外层对话框无法响应关闭，或按一次 Esc 关掉所有层 -
<dialog></dialog>的模态遮罩（::backdrop）是全局覆盖的，多个<dialog></dialog>会生成多个重叠遮罩，透明度叠加变深，视觉混乱 - 无障碍（a11y）层面完全失效：ARIA
aria-modal="true"和焦点陷阱逻辑只对单个活跃<dialog></dialog>生效，嵌套后屏幕阅读器无法正确识别层级和可交互区域
替代方案：单个 dialog + 动态内容切换
真正可行的做法是只保留一个 <dialog></dialog> 实例，通过 JS 控制其内部结构动态切换，模拟“多级”流程。关键点：
- 用
data-step或 class 控制子视图显隐，避免 DOM 反复增删 - 每次切换时手动管理焦点：用
element.focus()聚焦到新视图首个可聚焦元素（如<button></button>或<input>） - 监听
keydown捕获Escape，根据当前 step 决定是返回上一级还是关闭整个 dialog - 遮罩样式统一由
dialog::backdrop控制，无需额外 layer
示例简写：
<dialog id="flow-dialog"><div class="step" data-step="1">
<h3>第一步</h3>
<button onclick="goToStep(2)">下一步</button>
</div>
<div class="step hidden" data-step="2">
<h3>第二步</h3>
<button onclick="goToStep(1)">返回</button>
<button onclick="closeDialog()">完成</button>
</div>
</dialog>
需要真嵌套？换用自定义组件或库
如果业务逻辑强依赖“独立生命周期”的多层弹窗（比如主表单弹出子表单，子表单再弹出确认框），原生 <dialog></dialog> 就不是合适工具。此时应：
- 放弃
<dialog></dialog>，用<div role="dialog" aria-modal="true"> 自行实现，完整控制焦点陷阱、Esc 行为、遮罩和 a11y 属性 <li>引入轻量库如 <a href="https://www.php.cn/link/3276f901c702bc38cc36312a82ac5156">dialog-polyfill</a>（仅修复旧浏览器，不解决嵌套）或更现代的 <code>@headlessui/react/radix-ui/react-dialog，它们提供可组合的 Dialog.Root / Dialog.Trigger / Dialog.Content 结构，天然支持嵌套语义 - 注意：任何自定义方案都必须手动实现
focusin捕获、Tab循环、Escape逐层退出、以及aria-describedby等辅助属性，漏掉任意一项都会影响可用性
最常被忽略的是焦点回归——关闭内层对话框后，焦点必须准确回到外层触发按钮，而不是丢失在 body 上。这点原生 <dialog></dialog> 会自动处理，但自定义方案全靠你补全。
