z-index失效排查与解决指南

z-index看似失效，实则因它只在当前层叠上下文中起作用，而非全局生效——当父元素意外触发了层叠上下文（例如设置了opacity

z-index 为什么加了也没用

因为 z-index 只在**层叠上下文（stacking context）内部生效**，不是全局“谁数字大谁在上面”。父元素一旦创建了新的层叠上下文（比如设置了 opacity: 0.99、transform: translateZ(0)、will-change: transform，甚至 position: fixed），子元素的 z-index 就只能跟同级兄弟比，没法越过父级去跟外部元素抢层级。

• 常见错误现象：z-index: 9999 的弹窗被一个没设 z-index 的 header 盖住
• 实际原因：header 的父容器触发了层叠上下文（比如用了 filter: blur(1px)），而弹窗的父容器也独立创建了一个上下文，两者平级，浏览器按 DOM 顺序渲染——后出现的盖前面的
• 检查方法：在 Chrome DevTools 的 Elements 面板里选中元素，右侧 Styles 标签页下拉到底，看 Computed → “Stacking context” 是否显示 “Yes”

哪些 CSS 属性会悄悄创建层叠上下文

不是只有 position + z-index 才管用。很多看似无关的属性，只要值不为初始值，就会让元素变成层叠上下文根节点：

• position: fixed 或 position: sticky（即使没设 z-index）
• opacity 小于 1（opacity: 0.99 就够了）
• transform 不为 none（transform: translateZ(0)、rotate(0.0001deg) 都算）
• filter 不为 none（filter: blur(0.1px) 也会触发）
• will-change 设为 transform、opacity 等值
• isolation: isolate

怎么快速定位是哪个父元素“拦路”了

别一上来就改 z-index，先确认层叠上下文链路。目标元素能被盖住，说明它和遮挡者不在同一个上下文里，中间至少有一个“隔离父级”。

• 在 DevTools 中从目标元素往上逐级点击父节点，每点一个就看右侧面板的 “Stacking context” 是否变为 “Yes”
• 重点盯那些“没写 z-index 却突然变成 Yes”的父元素——大概率是它用了 opacity、transform 或 filter
• 临时删掉可疑样式（比如注释掉 filter），看遮挡是否消失；恢复后加 z-index: 0（显式创建上下文但保持默认层级）再测试
• 如果必须保留该样式（比如要做动画），那就得让遮挡者和目标元素处于同一上下文：把它们共同的最近层叠上下文祖先的 z-index 调高，而不是只调子元素

modal/tooltip 类组件的典型修复模式

这类组件常因封装层级深、父容器自带动效而失效。核心原则：**让 portal 挂载点脱离干扰上下文，或统一提升上下文入口**。

• 使用 createPortal（React）或手动 document.body.append() 把弹窗移出原有 DOM 树嵌套，避免继承父级上下文
• 如果不能移出（比如要跟随滚动定位），就在弹窗直接父容器上设 z-index: 1000，并确保该父容器本身没被其他上下文隔离（检查它的 opacity、transform）
• 不要依赖“父父父容器”的 z-index：哪怕它设了 z-index: 1，只要它自己是层叠上下文，子元素的 z-index: 9999 依然只在它内部有效
• 兼容性注意：transform: translateZ(0) 在旧版 Safari 下可能意外创建上下文，比 will-change 更隐蔽

真正卡住的往往不是 z-index 写小了，而是你根本没意识到某个 opacity: 0.999 已经把整个模块锁进了一个独立的“玻璃罩子”里。查上下文比调数字重要得多。

本篇关于《z-index失效排查与解决指南》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！