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 已经把整个模块锁进了一个独立的“玻璃罩子”里。查上下文比调数字重要得多。
