原生 默认隐藏且仅通过 javascript 方法控制显隐；必须作为 直接子元素，用 showmodal() 打开、close() 关闭，并正确处理焦点、遮罩和可访问性。
为什么直接写 <dialog></dialog> 不显示？必须调用 showModal()
很多人把 <dialog></dialog> 标签写进 HTML 后发现页面啥也没出现，检查 DOM 也存在，就是不渲染——根本原因是：原生 <dialog></dialog> 默认是隐藏态，且不会响应 CSS 的 display 或 visibility 切换。它只认 JavaScript 方法。
常见错误包括：
- 给
<dialog></dialog>写style="display: block"或加open属性（<dialog open></dialog>）——这只会让内容可见，但无遮罩、无焦点锁定、Esc 无效、点击 backdrop 不关闭 - DOM 尚未加载就调用
dialog.showModal()，报错Cannot read property 'showModal' of null - 把
<dialog></dialog>嵌套在<div class="container"> 之类容器里——backdrop 可能不渲染，尤其在 Safari 中<p>正确做法：</p> <ul> <li> <code><dialog></dialog>必须是的直接子元素 - 确保脚本执行时 DOM 已就绪，例如用
DOMContentLoaded或把<script></script>放在前 - 打开统一用
dialogEl.showModal()；关闭统一用dialogEl.close()（别设open = false，否则 backdrop 残留、close事件不触发）
dialog::backdrop 样式失效？兼容性与降级策略
dialog::backdrop 是控制遮罩层样式的唯一标准方式，但它在部分环境里不可靠：
- Safari 目前（截至 2026 年中）仍不支持自定义颜色，只能改
background-color的透明度（如rgba(0,0,0,0.4)），设纯色会 fallback 到默认灰黑 - 某些安卓 WebView（如旧版 UC、QQ 浏览器内核）完全忽略该伪元素
- CSS 优先级容易被重置，尤其当全局重置了
* { all: unset }时
实操建议：
- 先写
dialog::backdrop { background: rgba(0,0,0,0.5); }，作为现代浏览器主方案 - 对不支持的环境，用 JS 动态插入一个同级
<div class="dialog-backdrop">，并同步控制显隐（注意 z-index 高于 dialog）<li>避免在 <code>::backdrop中使用filter、transform等高开销属性，移动端易卡顿 dialog.addEventListener('click', e => { if (e.target === dialog) dialog.close(); })- 别用
stopPropagation()或preventDefault()去“禁用 backdrop 关闭”——这会同时破坏 Esc 关闭和屏幕阅读器逻辑 - 如果真要禁 backdrop 关闭（比如强确认弹窗），应移除该监听，而非阻止事件
- 移动端需额外加
touch-action: none到dialog上，防 iOS Safari 拖拽穿透 - 打开后立刻聚焦第一个可交互元素：
dialog.querySelector('input, select, button, [href]')?.focus() - 关闭后恢复焦点到触发按钮：
dialog.addEventListener('close', () => triggerBtn.focus())，注意用requestAnimationFrame包一层，避免 Safari 下失效 - 给
<dialog></dialog>加role="dialog"和aria-modal="true"，尤其在 Safari 15.3 及更早版本中必不可少 - 禁止背景滚动不能只靠
body { overflow: hidden }——它会让弹窗内长内容也无法滚动。稳妥做法是：打开前记下scrollTop，设body { position: fixed; top: -scrollTop }；关闭后还原
点击遮罩关闭弹窗，但误关内部按钮？事件判断要精准
原生 <dialog></dialog> 的 backdrop 不是独立 DOM 节点，点击遮罩时 e.target 就是 dialog 元素本身；而点击弹窗内容时，e.target 是内部按钮、输入框等子元素。很多人直接写 dialog.onclick = () => dialog.close()，结果一点按钮就关窗。
安全写法只有一条：
其他要点：
焦点管理不是可选项，而是可用性底线
没处理焦点的弹窗，在键盘用户或屏幕阅读器下等于不可用：Tab 键会跳到背景页、关闭后焦点丢失、Esc 失效……这些不是“体验差”，而是 WCAG 2.1 AA 级违例。
关键动作必须做：
最常被忽略的一点：<dialog></dialog> 必须有明确的关闭机制（至少一个按钮 + Esc），且不能依赖 hover 或 focus-visible 等非确定性交互——这对触屏设备和辅助技术是硬门槛。
