最常见原因是执行时机或DOM位置错误：脚本在dialog插入DOM前运行、dialog未直属于body、手动移除open属性、CSS干扰（如overflow:hidden）或未定义dialog::backdrop样式。
为什么dialog调用showModal()后仍不可见
最常见原因不是代码写错，而是执行时机或 DOM 位置不对。浏览器解析完 dialog 标签后默认不渲染任何内容，它完全惰性——不靠 CSS 控制显隐，只靠 JS 方法激活。
-
document.querySelector('dialog')返回null：脚本在<dialog></dialog>插入 DOM 前就执行了，比如放在里或未加DOMContentLoaded监听 -
dialog不在直接子级：嵌套在<div class="container"> 或带 <code>transform的父容器中时，Safari 和部分 Chrome 版本会裁剪dialog::backdrop，甚至让弹窗整体偏移 - 手动删了
open属性：调用showModal()会自动添加open，但后续若执行dialog.removeAttribute('open')，弹窗就“消失”了——DOM 还在，只是被浏览器判定为未激活 - CSS 干扰：父级有
overflow: hidden或will-change: transform，会截断 backdrop 渲染或抬升堆叠上下文，导致遮罩盖不住背景 - 必须声明：
dialog::backdrop { background-color: rgba(0, 0, 0, 0.6); }，否则用户感知不到模态状态 - 不要用
display: none或visibility: hidden控制 dialog 显隐——这会破坏焦点流和浏览器内置的焦点归还逻辑 - Safari 17.4+ 才支持
dialog::backdrop上的transition动画；此前版本只能做硬切 - 避免对
dialog::backdrop绑定事件监听器：它不是真实 DOM 节点，无法可靠触发click - 兼容写法：监听
dialog的click事件，再用getBoundingClientRect()判断点击坐标是否落在弹窗区域外 - 降级方案更稳：直接放一个“取消”按钮，或用
form[method="dialog"]+type="reset"按钮，语义清晰且无需 JS 判断 - 别写
dialog::backdrop { pointer-events: none; }——这会让所有点击穿透，连弹窗内按钮都点不了 - 必须用
<button value="confirm">确定</button>：只有带value属性的submit按钮，其值才会赋给dialog.returnValue - 禁止
event.preventDefault()或onsubmit="return false"：它们会中断原生关闭流程，导致弹窗卡住 - 关闭后读值要等
close事件：不能在click回调里立刻读dialog.returnValue，得监听dialog.addEventListener('close', () => console.log(dialog.returnValue)) -
type="reset"按钮不会设returnValue，适合“拒绝”场景，但需手动调dialog.close()
dialog::backdrop样式必须手写，且不能省略
原生 dialog 不自带 backdrop 可视化效果。Chrome/Edge 默认给 backdrop 加了极淡的灰（rgba(0,0,0,0.01)），Firefox 甚至不渲染 backdrop 元素本身，只保留逻辑阻塞。不写样式 = 遮罩不可见 + 点击无反馈。
点击遮罩关闭弹窗在 Safari 中基本不可靠
原生 dialog 没有内置“点击 backdrop 关闭”的行为。各浏览器实现差异极大：Chrome/Edge 120+ 支持 e.target === dialog 判断；Firefox 不触发 backdrop 相关事件；Safari 15.4–17.6 中，事件路径不可靠，e.target 几乎永远不会等于 dialog 元素。
form[method="dialog"] 提交后怎么安全取值并关闭
这是最轻量的数据回传路径，但细节一错就拿不到 dialog.returnValue，或者表单提交后弹窗不关。
立即学习“前端免费学习笔记（深入）”；
dialog 的性能优势不在渲染速度，而在交互链路的“零接管”——它不抢焦点管理、不劫持 Esc 键、不伪造遮罩层。但这些优势全依赖你避开 DOM 位置、样式边界和事件路径这三类隐藏陷阱。稍一松懈，就会退回“和浏览器打架”的老路。
