原生 dialog 无法真正全屏，因浏览器强制 position: absolute 和 z-index，设 100vw/vh 会破坏焦点锁定、backdrop 行为及 Safari 渲染；应改用 dialog 承载全屏内容并控制容器布局，配合 flex 和 overflow 处理滚动，用 Escape 键关闭，降级需 polyfill 保障可访问性。
dialog 标签本身不支持“全屏弹窗”——它默认居中、有内边距、带圆角，且浏览器强制施加 position: absolute 和高 z-index，强行拉满宽高会破坏焦点锁定和 backdrop 行为，尤其在 Safari 中极易错位或失焦。
为什么不能直接设 width:100vw; height:100vh
原生 dialog 的渲染机制决定了它不是普通块级元素：
• Chrome/Firefox 会忽略 width: 100vw，仍按内容撑开，且左右留白（默认 margin）
• Safari 对 transform、will-change 父容器极其敏感，一旦父级有这些声明，dialog 可能完全消失或偏移出视口
• 即使样式生效，::backdrop 也不随弹窗尺寸扩展——遮罩层仍是居中区域的灰层，外部区域可点击、可滚动、可聚焦，模态性失效
• 全屏后第一个可聚焦元素可能被裁剪，showModal() 自动聚焦失败，键盘用户卡死
真正可用的“全屏效果”实现方式
放弃“让 dialog 全屏”，转而用它承载全屏内容，并控制其容器行为：
- 给
dialog设margin: 0; width: 100%; height: 100%; max-width: none; max-height: none;，再用display: flex; flex-direction: column;布局内部 - 内部第一层子元素（如
<div class="fullscreen-content">）设flex: 1; overflow: auto;，保证内容可滚动而非溢出 - 遮罩层视觉增强：用
dialog::backdrop { background: #000; opacity: 0.9; }（注意 Safari 目前仍不支持::backdrop，需降级） - 移动端必须加
@media (max-width: 768px) { dialog { width: 100vw; height: 100vh; } }，否则 iOS Safari 会缩放错乱
点击遮罩关闭在全屏场景下更不可靠
当 dialog 尺寸接近视口时，e.target === dialog 判断基本失效——Safari 中事件路径不可靠，Chrome 中点到边缘可能触发，也可能不触发：
立即学习“前端免费学习笔记（深入）”；
- 不要依赖
click事件判断 backdrop：它在 Safari 15.4–17.6 中始终返回false - 改用
keydown监听Escape键，这是唯一跨浏览器稳定的关闭触发器 - 若必须支持点击关闭，手动插入一个同层级
<div class="backdrop">，用 JS 控制显隐，并绑定click到它身上（此时需同步管理inert或aria-hidden） - 关闭后务必手动调用触发按钮的
.focus()，否则键盘焦点丢失，WCAG 2.4.3 不达标
兼容性补丁比样式更重要
截至 2026 年 9 月，iOS Safari 17.6 仍不支持 dialog.returnValue，且 ::backdrop 在所有 Safari 版本中均不可编程；所谓“全屏”在旧 WebView 中大概率表现为错位弹窗或无遮罩白屏：
- 运行时检测必须写成：
if (!('showModal' in HTMLDialogElement.prototype) || !CSS.supports('selector(::backdrop)')) - 降级方案不能只隐藏
dialog显示div，必须补全：inert属性切换、Tab焦点陷阱、Escape监听、aria-modal同步 - 推荐直接引入
dialog-polyfill，它已适配 Safari 的 focus 锁定缺陷和 backdrop 模拟逻辑，比手写降级稳定得多
真正的难点不在“怎么拉满尺寸”，而在“如何不让全屏破坏模态语义”——焦点是否可循环、遮罩是否真阻断、键盘是否全程可控，这些细节一漏，就不是弹窗，是可访问性陷阱。
