z-index无效的根本原因是层叠上下文被意外触发，导致子元素z-index仅在局部生效；常见触发条件包括非static定位且设z-index、opacity
z-index 值没形成层级上下文就无效
多个弹窗叠在一起却乱序，大概率不是 z-index 没写，而是父容器触发了新的层叠上下文（stacking context），导致子元素的 z-index 只在该上下文中比较，不和外部弹窗竞争。
常见触发条件包括：position 不是 static 且设置了 z-index、opacity 小于 1、transform 非 none、filter 有值、will-change 指定某些属性等。只要父级弹窗容器满足其一，它内部所有弹窗就“自成一国”，彼此能排序，但无法越过这个父级去和页面其他弹窗比高低。
- 检查最外层弹窗容器是否意外加了
opacity: 0.99或transform: translateZ(0) - 用浏览器开发者工具的“Layers”面板或“Computed”标签页，看弹窗节点是否被标记为 “Stacking Context”
- 临时移除父级非必要样式（如
filter、will-change），确认是否恢复预期顺序
多个弹窗共用同一父容器时 z-index 失效
如果所有弹窗都挂载在同一个 DOM 节点下（比如 document.body 或一个全局 #modal-root），它们本应处于同一层叠上下文中，此时 z-index 应该直接生效。但实际仍错乱，往往是因为：
- 部分弹窗用了
position: static（z-index对它完全无效） - 部分弹窗用了
position: relative却没设z-index，按文档流顺序叠加，而非数值大小 - 不同弹窗组件动态插入时，DOM 顺序和
z-index数值不一致，比如后打开的弹窗z-index是 100，但 DOM 在前，而先打开的弹窗z-index是 200，但 DOM 在后 —— 此时后者会盖住前者（因为同级中 DOM 后序 >z-index）
解决办法是统一管理：确保所有弹窗都用 position: fixed 或 position: absolute，并由一个中央逻辑分配递增的 z-index 值，同时保证新弹窗 DOM 插入到父容器末尾。
立即学习“前端免费学习笔记（深入）”；
React/Vue 中动态弹窗的 z-index 同步问题
框架里弹窗常通过 v-if / useState 控制显隐，但显隐切换本身不重置 z-index，容易出现“关闭高 zIndex 弹窗后，新弹窗拿到低值，被残留的旧弹窗遮挡”这类问题。
典型错误模式：
const [zIndex, setZIndex] = useState(1000); // 每次打开都 +1，但关闭时不回收，也不重置 const openModal = () => setZIndex(prev => prev + 1);
更稳妥的做法是维护一个全局计数器，每次打开新弹窗时取当前最大值 + 1，并记录该弹窗 ID 对应的 zIndex；关闭时不清空，只确保新开的一定比所有现存的高：
- 用
useRef或模块级变量存当前最高z-index值（如let nextZIndex = 1000） - 打开弹窗时执行
const currentZ = nextZIndex++并传给组件 - 避免依赖组件自身状态更新
z-index，防止异步或批量更新导致冲突
移动端 Safari 的 z-index 渲染异常
iOS Safari（尤其旧版本）对 z-index 和 transform 组合非常敏感。即使你没主动加 transform，某些 CSS 框架或 UI 库的动画类（如 animate-fade-in）可能悄悄加了 transform: translateZ(0)，从而创建隐式层叠上下文。
排查建议：
- 在 Safari 开发者工具中禁用所有
transform、opacity、filter相关样式，看是否恢复正常 - 对弹窗根元素显式设置
transform: none !important和backface-visibility: hidden（后者有时可缓解渲染错位） - 避免在弹窗上使用
will-change: transform，除非真有高频 transform 动画
真正难缠的不是 z-index 写多少，而是搞清谁在中间“截胡”了层叠上下文 —— 浏览器不会告诉你它默默建了个新世界，只会让你看到结果乱了。
