为什么z-index 999还被挡住？同级元素层叠顺序解析

你以为设了z-index: 999就高枕无忧？其实它可能根本不起作用——真正决定元素谁在前、谁在后的，不是数字大小，而是层叠上下文的层级结构：只有定位元素（position不为static）才能参与z-index比较，而一旦父元素触发了新的层叠上下文（比如设置了opacity

z-index:999 无效？先确认是否在同一个层叠上下文里

直接给元素设 z-index: 999 却被挡住，大概率不是值不够大，而是它和遮挡它的元素根本不在同一个“Z轴空间”里。CSS 的 z-index 只在**同一层叠上下文（stacking context）内**生效。一旦父容器自己创建了新的层叠上下文（比如设置了 z-index、opacity、transform 等），子元素的 z-index 就只在这个小空间里比大小，再高也跨不出去。

• 常见触发新层叠上下文的父级样式：position: relative + z-index: 0（或任意非 auto 值）、opacity: 0.99、transform: translateZ(0)、will-change: transform
• 浏览器 DevTools 中，选中元素后在 “Computed” 面板里搜 stacking context，能快速判断它是否是某个上下文的根
• 如果遮挡者是父元素（比如弹窗内部的按钮被弹窗背景盖住），检查父元素是否意外触发了层叠上下文 —— 很多时候只是加了个 z-index: 0 或 opacity: 0.999 就够了

同级元素没设置 z-index，谁在上面？看 HTML 顺序和默认堆叠规则

两个 position: relative 或 position: absolute 的同级元素，都没写 z-index，那谁压谁？答案是：**后写的那个在上面** —— 这是 CSS 默认的“后来者居上”规则。但要注意，这个规则只在它们属于同一个层叠上下文、且 z-index 都为 auto 时才起作用。

• z-index: auto（未显式声明）的定位元素，默认不参与层级比较，按源码顺序堆叠
• z-index: 0 和 z-index: auto 不等价：前者会创建新层叠上下文，后者不会
• 如果一个同级元素写了 z-index: 1，另一个没写，那写了的那个一定在上面；但如果两者都写了，数值大的胜出

检查父容器的 position 和 z-index 是否“锁死”了子元素层级

子元素设了 z-index: 999，父容器却设了 z-index: 1，结果子元素还是被兄弟容器（z-index: 100）挡住 —— 这不是 bug，是预期行为。因为子元素的 z-index 是相对于父容器的层叠上下文计算的，它最多只能“撑满”父容器所占的 Z 层高度，无法突破父容器在整个页面中的层级位置。

• 父容器 z-index: 1 → 它在页面中 Z 层排第 1 位；子元素 z-index: 999 → 它在父容器内部 Z 层排第 999 位，但对外仍属于“第 1 层”
• 要让子元素真正“浮出来”，必须提升它的父容器层级，或者把该子元素移出当前父容器（比如用 portal 或动态挂到 body 下）
• 特别注意：position: fixed 元素默认以视口为包含块，但它依然受其最近层叠上下文约束（比如被 opacity

为什么 Chrome DevTools 显示 z-index 生效，但视觉上还是被盖？

DevTools 的 Styles 面板显示 z-index: 999 已应用，不代表它真的“赢了”。可能原因包括：

• 目标元素实际被更外层的层叠上下文包裹（比如整个导航栏用了 transform，导致内部所有 z-index 失效）
• 遮挡者是 <select>、