子元素的z-index无效是因为父级创建了层叠上下文，将其层级比较范围限制在内部；需检查并调整父容器z-index或移除触发上下文的属性（如transform、opacity），而非盲目提高子元素z-index。
子元素的 z-index 无效，不是它没生效，而是它根本“出不去”父级创建的层叠上下文——这个上下文像一层玻璃罩，把子元素的层级比较范围锁死在里面。
子元素加了 z-index 却被父级外的元素盖住
这是最典型的误判场景：你给弹窗内部的按钮设了 z-index: 9999，结果它还是被 header 盖住。原因不是按钮不够高，而是按钮的父容器（比如一个带 transform: translateY(0) 的卡片）已创建新层叠上下文，按钮的 z-index 只能跟同级兄弟比，无法跨出去挑战 header 所在的上下文。
- 检查目标元素的 computed
z-index：如果显示为(not applicable)或灰显，说明它未定位或被隔离 - 用 Chrome DevTools 逐级点击父节点，在右侧面板的 «Computed» 标签下搜
Stacking context，第一个标为Yes的祖先就是“结界源头” - 临时注释掉父级的
opacity、transform、filter，看遮挡是否立即消失——这是最快验证手段
为什么 position: relative + z-index: 0 就会截断层级
z-index: 0 和 z-index: auto 行为完全不同：z-index: 0 会显式创建新层叠上下文，而 z-index: auto 不会（前提是元素已定位）。很多组件库默认给 wrapper 加 position: relative; z-index: 0，本意是“兜底”，结果反而成了层级隔离器。
- 不要对非必要容器加
z-index，哪怕只是0；优先用z-index: auto或干脆不写 - 若父容器必须有定位（如做动画锚点），但又不想创建上下文，就只写
position: relative，别碰z-index - 注意
flex或grid容器中，子项一旦设了z-index（非auto），也会触发上下文——这常被忽略
修复时该调子元素还是父容器的 z-index
答案很明确：优先调父容器。子元素再高的 z-index 也破不了父级的上下文边界，但父容器自身的 z-index 决定了整个“小世界”在全局的起始高度。
立即学习“前端免费学习笔记（深入）”；
- 如果父容器加
transform是为动画过渡，且可删，直接移除——比堆数字干净十倍 - 如果必须保留（如淡入/模糊效果），就把父容器自身设为高
z-index，例如z-index: 1050，而不是只给子弹窗设9999 - 对 modal/tooltip 类组件，更彻底的解法是用
createPortal（React）或Teleport（Vue）挂到body下，完全脱离干扰上下文
真正难的不是改哪一行 CSS，而是意识到：z-index 不是独立变量，它是嵌套在层叠上下文树里的相对值。每次想加个 9999 前，先往上点三下 DevTools —— 那个突然标红的 Stacking context: Yes 才是你该修的地方。
