最轻量语义方案是用 + web components 封装，但需处理生命周期、open 同步、焦点控制及 safari 兼容降级；不可继承 htmldialogelement（safari 不支持），应以 包裹外部 并挂载到 document.body，通过 slot 透传内容、暴露 open 属性与 showmodal()/close() 方法，确保焦点锁、esc 响应和无障碍支持，并为 safari 降级实现 backdrop。
直接用 <dialog></dialog> 元素 + Web Components 封装是最轻量、语义最正的方案，但必须处理好生命周期、open 属性同步、焦点控制和 Safari 兼容降级——别把 Web Component 当成 div 的语法糖来套。
为什么不能直接 extends HTMLDialogElement？
Chrome/Firefox 支持自定义元素继承原生标签（如 class MyDialog extends HTMLDialogElement），但 Safari 目前完全不支持该语法，调用 customElements.define('my-dialog', MyDialog, { extends: 'dialog' }) 会静默失败。强行使用会导致组件在 Safari 中彻底不渲染，且无法 fallback。
实操建议：
- 放弃继承原生
<dialog></dialog>，改用<my-dialog></my-dialog>自定义标签包裹一个内部<dialog></dialog>或<div role="dialog"> <li>组件内通过 <code>shadowRoot渲染结构，避免样式污染，但注意<dialog></dialog>必须是的直接子元素才能触发 backdrop，所以不能放在 shadow DOM 里 - 正确做法：组件负责管理状态与 API，真实
<dialog></dialog>插入到document.body顶层，再用slot或属性透传内容 -
open属性：响应式布尔值，<my-dialog open></my-dialog>立即显示，移除即关闭；需监听attributeChangedCallback同步到内部<dialog></dialog> -
showModal()方法：对外暴露标准模态行为入口，内部调用this._dialog.showModal()，并确保聚焦第一个可交互元素 -
close()方法：必须触发close事件，并清理焦点锁、恢复body滚动 -
textContent/innerHTML不要直接暴露——改用<slot></slot>让用户写内容，更安全、更符合 Web Components 设计哲学 - 打开时，先确保内部
<dialog></dialog>已 append 到document.body，再调用.showModal()，最后focus()到其内部第一个button或input - ESC 监听必须挂在
document上（不能只挂组件实例），并判断event.target === this._dialog || this._dialog.contains(event.target)，防止干扰其他模态框 - 关闭后，用
this._lastFocused?.focus()恢复上一焦点元素，this._lastFocused = document.activeElement要在打开前就记录 - 给内部
<dialog></dialog>显式加role="dialog"、aria-modal="true"、aria-labelledby，ID 必须唯一且可被屏幕阅读器解析 - 检测是否支持：
const supportsBackdrop = CSS.supports('selector', 'dialog::backdrop') - 不支持时，在
document.body动态插入一个<div class="my-dialog-backdrop">，z-index 设为 999，样式全由 CSS 控制 <li>这个 backdrop 元素必须和 <code><dialog></dialog>同级、同生命周期，showModal()前显示，close()后隐藏或 remove - 别试图用
transform: scale()模拟 backdrop，它会破坏点击穿透判定和滚动锁定
<my-dialog></my-dialog> 组件必须暴露哪些 API？
用户调用时只关心「怎么开」「怎么关」「怎么传内容」，而不是 DOM 操作细节。暴露过多底层方法（如 show()、hide()）反而增加误用风险。
关键接口应为：
焦点锁和 ESC 关闭为什么总失效？
Web Components 的 shadow boundary 会中断 focus() 和键盘事件捕获链。常见现象：弹窗打开后 Tab 键仍能跳到背景按钮、按 ESC 没反应、屏幕阅读器读不到弹窗标题。
根本原因不是 JS 写错，而是焦点没真正落到 shadow 内部或事件没穿透。
解决要点：
移动端 Safari 的 dialog::backdrop 样式为何不生效？
Safari 目前（截至 2026 年 5 月）仍不支持 dialog::backdrop 伪元素的背景色、模糊等样式设置，只能控制透明度。这意味着你写的 dialog::backdrop { background: rgba(0,0,0,0.7); } 在 Safari 中完全无效，遮罩层始终是纯黑半透明。
兼容方案不是“加 polyfill”，而是主动降级：
Web Components 弹窗最难的不是渲染，而是跨浏览器的焦点流与模态语义一致性。Safari 的 dialog 行为差异、shadow DOM 对事件流的截断、以及移动端滚动锁定的实现方式，三者叠加后很容易漏掉一个环节就导致键盘用户无法操作——这不是“加个 tabindex”就能解决的表面问题。
