原生 dialog 未调用 showmodal() 时不参与渲染；调用后强制同步布局，需确保其为 body 直接子节点、内部元素设宽高、避免 transform 干扰，并用 method="dialog" 提交表单以零重排关闭。
dialog 元素本身不触发重排，但错误调用会强制同步布局
原生 dialog 在未调用 showModal() 时完全不参与渲染流程：它被浏览器标记为 display: none、跳过布局计算、getBoundingClientRect() 返回空对象。这点和 visibility: hidden 或 opacity: 0 完全不同——后者仍占布局空间、仍参与样式计算。
但一旦调用 showModal()，浏览器必须立刻完成三件事：生成 ::backdrop、锁定焦点、计算 dialog 自身的居中位置。这个过程会触发一次强制同步布局（forced reflow），尤其当 dialog 内部有未设宽高的图片、或依赖 flex 动态计算尺寸的子元素时，成本会上升。
- 避免在
showModal()前动态插入大量 DOM 节点；先 append 子元素，再调用方法 - dialog 内部所有
<img>必须带width和height属性，否则加载时会触发布局抖动（CLS） - 别在
dialog上写transform: scale(0)+ CSS 动画过渡——这会让浏览器误判为需合成层，反而增加 GPU 开销 - 若需动画入场，用
dialog[open]伪类配合opacity和scale，并在showModal()后立即requestAnimationFrame触发
dialog 放错位置会破坏浏览器默认居中逻辑，导致回流加剧
dialog 的居中行为不是靠 CSS 实现的，而是浏览器内置的“顶层浮层”定位策略。它要求元素必须是 的直接子节点。一旦嵌套进 <div class="app">、<code><main></main> 或任何设置了 position: relative / transform / will-change 的父容器，浏览器就无法正确计算视口中心，转而退化为普通绝对定位——此时你看到的“偏移”，其实是多次 layout 计算失败后的 fallback 结果。
- 检查 DevTools Elements 面板中
dialog的父节点是否为body；不是就移动 DOM 节点 - 禁用父级的
transform（哪怕只是translateZ(0)）和will-change: transform，这两者会切断 dialog 的定位上下文 - Safari 中若 dialog 显示位置异常，大概率是父容器有
overflow: hidden或clip-path，需移除 - 不要手动写
dialog { position: absolute; top: 50%; left: 50%; transform: translate(-50%, -50%); }—— 这绕过原生逻辑，且在多屏缩放下失效
监听 backdrop 点击关闭时，事件处理不当会引发额外重绘
::backdrop 默认不可点击、不冒泡、无交互语义。你写的 dialog.addEventListener('click', ...) 实际监听的是 dialog 元素自身的点击区域（含 backdrop 和内容区）。但 Safari 15.4–16.3 存在 bug：点击 backdrop 时 e.target 总是 body，而非 dialog，导致判断失效。若 fallback 到坐标检测（如 e.clientX ），每次点击都会触发 <code>getBoundingClientRect()，进而强制同步布局。
- 只在
showModal()后绑定一次 click 监听器，不要每次打开都重复 addEventListener - 使用
dialog.hasAttribute('open')替代dialog.open === true判断状态，更可靠 - 对 Safari 做轻量 fallback：先检查
e.target === dialog，不成立时再用dialog.contains(e.target)，避免直接调用 getBoundingClientRect() - 别给
dialog::backdrop加transition: opacity .3s—— backdrop 本身无重绘优化，动画会持续触发 paint
表单提交刷新页面？method="dialog" 是唯一零重排解法
在 dialog 里放 <form></form> 是常见需求，但默认提交会整页 reload，造成“弹窗闪退”。很多人用 e.preventDefault() + fetch + dialog.close()，看似合理，实则埋雷：异步请求期间用户可能反复点击按钮，或网络延迟导致 close() 被多次调用，甚至 dialog 已关闭却还在操作 DOM。
- 优先用
<form method="dialog"></form>：提交后自动触发close()并设置dialog.returnValue，整个过程不触发任何 layout 或 paint - 仅当必须异步提交时，才用
submit事件 +e.preventDefault()，且关闭前加防抖：if (!dialog.open) return - 别在按钮
onclick里写dialog.close()：用户按回车提交表单时不会触发该 handler，导致焦点卡死 - 关闭后清理资源应在
dialog.addEventListener('close', ...)中做，而不是 submit 回调里——close 事件保证 dialog 已退出模态状态
真正影响性能的从来不是 dialog 标签本身，而是你如何让它和浏览器渲染管线协同工作。焦点管理错位、DOM 位置违规、事件监听冗余——这些细节出问题，比写错一个 CSS 属性更容易让页面卡顿。
