fixed弹窗叠在同一位置因均用固定top值且不参与文档流；需JS动态计算每个弹窗的top，基于已存在弹窗的实际高度与间距累加，并排除正在关闭的节点，确保DOM顺序、视觉状态与布局同步。
fixed定位弹窗为什么总叠在同一个位置
因为所有弹窗都用 top: 20px 这类固定值，浏览器不会自动避让。position: fixed 是相对于视口的绝对定位，不参与文档流，彼此之间毫无感知——你加十个，它们全挤在 top: 20px 那条线上。
真正要堆叠，得靠 JS 动态算每个弹窗的 top 值，让后一个比前一个往下挪一段距离（比如弹窗高度 + 间距）。
- 别用 CSS 动画或 transition 控制堆叠顺序，那只是视觉错觉，DOM 顺序和定位值没变
- 弹窗 DOM 节点必须按显示顺序追加到 body 末尾，否则 JS 拿
document.querySelectorAll('.toast')会漏掉或顺序错乱 - 高度不能写死：用
getBoundingClientRect().height读真实渲染高，避免 padding/margin/border 导致计算偏移
JS里怎么安全累加top值
关键不是“加多少”，而是“加给谁”和“加几次”。常见错误是每次 show() 都遍历全部弹窗重算 top，结果旧弹窗被反复修改、动画跳动、z-index 错乱。
正确做法是：只算新弹窗自己的 top，基于当前已存在的弹窗数量和它们的实际高度推导。
立即学习“前端免费学习笔记（深入）”；
- 维护一个全局计数器（如
window.toastCount）不可靠——弹窗可能手动关闭，计数易不同步 - 应实时查 DOM：
const toasts = document.querySelectorAll('.toast:not(.closing)')，排除正在 fade-out 的节点 - 逐个读
toast.getBoundingClientRect().height并累加，再加统一间距（如12px），作为新弹窗的top - 示例逻辑：
const offset = [...toasts].reduce((sum, t) => sum + t.getBoundingClientRect().height + 12, 0);<br>newToast.style.top = `${offset}px`;
滚动时右上角弹窗为啥会“漂移”
position: fixed 本该锚定视口，但如果父容器有 transform、perspective 或 will-change，就会创建新的 containing block，导致 fixed 脱离视口，转而相对那个父容器定位。
典型场景：用了 antd / element-plus 的 Drawer、Modal，或自己写了带 transform: translateZ(0) 的 wrapper。
- 检查弹窗父级是否有任何
transform值（包括translateX(0)这种看似无害的） - 用 Chrome DevTools 的 “Layers” 面板看弹窗是否被包进某个合成层（Composited Layer）
- 强制修复方式：给弹窗加
style="transform: translateZ(0)"可能反而恶化问题；更稳的是确保弹窗直接挂载到document.body，且 body 上没有触发新 containing block 的样式
多个弹窗同时关闭时堆叠错乱怎么办
关闭动画（如 opacity: 0 + transition）进行中时，JS 仍把它当有效弹窗算进高度，但视觉上它已收缩或透明，造成后续弹窗位置悬空。
本质是 DOM 存在性、视觉可见性、布局占用三者不同步。
- 不要等
transitionend再从 DOM 删除节点——太慢，堆叠计算已出错 - 关闭时立刻加 class（如
.toast.closing），并在 JS 计算时过滤掉：document.querySelectorAll('.toast:not(.closing)') - CSS 中用
.closing { pointer-events: none; opacity: 0; transform: translateY(-10px); }，既保持占位（避免重排闪动），又明确标记状态 - 动画结束后用
setTimeout(() => el.remove(), 300)清理 DOM（300 对应 transition duration）
堆叠逻辑本身不复杂，难的是把 DOM 状态、CSS 渲染周期、JS 执行时机这三件事对齐。稍有错位，用户就看到弹窗互相穿透、位置跳变、关不干净——这些都不是定位写错了，是生命周期没管住。
