fixed弹窗堆叠必须用js计算top，因所有弹窗均相对于视口定位、彼此不感知，相同top值会导致重叠；需动态累加可见弹窗高度与间距，并排除过渡中或隐藏节点，确保视觉堆叠准确。
fixed弹窗堆叠为什么必须用JS算top
因为所有通知都用position: fixed，它们彼此不感知、不避让——哪怕你加10个，只要top值相同，就全挤在一条水平线上。CSS本身没有“自动堆叠”能力，z-index只管前后遮挡，不管上下间距。真正实现右上角逐个下移的堆叠效果，必须靠JS读取已存在弹窗的实际高度（含margin/padding/border），累加计算新弹窗的top值。
- 别依赖
getBoundingClientRect().height后直接+固定间距：要排除正在执行remove()或opacity: 0过渡中的节点，否则计算结果滞后 - 别用
offsetHeight：它不包含transition中的尺寸变化，也不反映display: none前的最终渲染高度 - 推荐组合：
getBoundingClientRect().height + 12（12px为视觉间距），再对每个存活弹窗循环累加
如何安全获取当前所有可见弹窗的高度总和
关键不是“有多少个”，而是“哪些还在视觉上占据空间”。DOM中可能残留着刚触发remove()但动画未结束的节点，或者visibility: hidden但仍在布局中的元素。必须过滤掉它们，否则top会越算越大、错位越来越严重。
- 用
document.querySelectorAll('.toast:not(.closing):not([style*="display: none"])')筛选——.closing是手动加的过渡中标识类 - 对每个匹配节点调用
getBoundingClientRect()前，先检查offsetParent !== null，排除display: none或父级不可见的情况 - 如果弹窗用了
transform: scale(0)做隐藏，getBoundingClientRect()仍返回0，需额外判断computedStyle.transform !== 'none'
为什么弹窗挂载到document.body比嵌套在组件里更稳
一旦父容器有transform、perspective、will-change或filter，就会创建新的containing block，导致position: fixed失效——弹窗不再相对于视口定位，而是相对于那个父容器。这种隐式行为很难排查，尤其在React/Vue组件树深层嵌套时。
- 强制修复方式如
transform: translateZ(0)可能加剧问题，因为它本身就会触发新containing block - 最可靠做法：所有全局通知统一用
document.body.appendChild(toastEl)插入，且确保body上没设上述属性 - 若必须嵌套（如微前端场景），给弹窗加
style="position: fixed !important; top: auto !important;"并用JS重写top，绕过CSS继承干扰
堆叠偏移量计算容易漏掉的三个细节
很多实现看似能堆叠，但滚动页面、缩放窗口或快速连续触发时就错位——问题往往出在边界条件没处理。
-
getBoundingClientRect()返回的是视口坐标，但页面滚动时，弹窗top值应基于视口顶部而非文档顶部；无需手动减window.scrollY，因为fixed本就锚定视口 - 弹窗内容动态加载（如带图片）会导致高度变化，首次计算完
top后，图片加载完成又撑高了，必须监听img的load事件并重新计算该弹窗及后续所有弹窗的top - 移动端键盘弹起时，
visualViewport.height会变小，但getBoundingClientRect()仍按原视口算——此时需监听resize和focusin事件，对受影响弹窗重排
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
