z-index设了没反应，主因是元素未定位（position为static时z-index被忽略）或父级创建了层叠上下文导致子元素z-index仅在内部生效；需显式设置position并检查祖先节点是否触发stacking context。
z-index 为什么设了却没反应
遇到z-index不生效，先别急着把数值调到9999。绝大多数时候，问题压根不在数值大小，而是z-index根本没被浏览器“认出来”——它只对定位元素有效。只要元素的position属性是默认的static，无论你写z-index: 9999还是z-index: -9999，都会被直接无视。
下面这几种情况，是不是看着很眼熟？
- 明明给元素加了
z-index: 100，可它还是被死死压在下面。 - 用Ja vaScript动态添加样式后，层级突然乱套，十有八九是漏写了
position。 - 父元素设了
position: relative，就误以为子元素能“继承”这个定位上下文，结果子元素的z-index照样失效。
怎么解决？记住这几个实操要点：
- 最稳妥的办法：给目标元素显式加上
position: relative。它通常最安全，不会打乱原有的文档流。 - 别被
position: static迷惑——它不是“没写position”，而是明确声明了“禁止定位和z-index”。 - 小心
position: sticky：当元素滚动到边界后，它会退化成relative，这时z-index的行为可能会发生意想不到的变化。
父容器悄悄创建了层叠上下文
如果说元素没定位是“明枪”，那父级创建层叠上下文就是“暗箭”，隐蔽且极易被忽略。一旦某个祖先元素触发了层叠上下文，它就像给所有子元素划了一个“结界”。子元素的z-index再高，也只能在这个结界内部比个高低，根本出不去，更别提和结界外的元素较量了。
那么，哪些属性会触发这个“结界”呢？检查所有祖先节点时，请重点关注：
opacity小于1（哪怕是opacity: 0.99）。transform不为none（即使只是transform: translateZ(0)这种看似无害的操作）。- 还有
filter、will-change、isolation: isolate这些属性。 - 甚至
contain: layout或contain: paint也可能触发。
排查和解决的建议如下：
- 打开Chrome开发者工具，在「Computed」面板里搜索“Stacking Context”，看看是否有祖先节点被标记为“This element establishes a stacking context”。
- 一个快速验证法：临时删掉可疑父元素的
transform或opacity属性，观察子元素是不是立刻就能“浮上来”。 - 如果这些属性非用不可，可以考虑把它们上移到更高层级的容器（比如直接挂在
body下的包装器上），而不是套在目标元素的紧邻父级。
父元素 z-index 值太低，子元素再高也没用
这里有个关键概念：子元素的z-index是相对于其**直接父级所在的层叠上下文**生效的。想象一下，如果父容器的z-index只有2，而它旁边的一个兄弟容器的z-index是100，那么整个父容器子树（包括里面z-index再高的子元素）都会被压在下面。因为层叠比较发生在同级容器之间，子元素无法“穿透”父级的层级壁垒。
典型场景包括：
- 轮播图组件里弹出的操作按钮，被页面顶部的导航栏遮住。
- 下拉菜单展开后，莫名其妙被下方某个
section的背景色盖住。 - Modal弹窗组件嵌套在一个带了
transform的卡片里，无论怎么调z-index都无济于事。
应对策略可以这样考虑：
- 确保那些需要全局高层的元素（比如弹窗、下拉菜单、提示框），它们的最近共同祖先**没有提前创建层叠上下文**。
- 更彻底的做法：利用React的Portal或Vue的Teleport，直接把这类元素挂载到
body下，从根本上绕过DOM层级带来的干扰。 - 切忌盲目堆砌大数值——
z-index: 999999解决不了上下文隔离的问题，只会给后续维护埋下更深的坑。
DOM 顺序或 flex/grid 排序覆盖了 z-index
即便z-index正常生效了，也可能被CSS更底层的渲染规则覆盖。CSS的层叠顺序有一套固定的优先级：层叠上下文 > z-index值 > 文档流顺序（后出现的盖住前面的） > flex的order或grid的放置顺序。
有几个容易忽视的细节：
- 当两个元素的
z-index值相同时，谁在HTML结构里写在后面，谁就显示在上面。 - Flex容器中如果设置了
order属性，可能会导致视觉顺序和DOM顺序不一致，从而影响最终的层叠效果。 - Grid布局中，
grid-row和grid-column带来的隐式层叠行为，有时也会凌驾于z-index之上。
调试时可以遵循以下建议：
- 先暂时去掉所有
z-index，仅凭DOM的先后顺序，来确认基础的覆盖关系是否合理。 - 在flex或grid容器上谨慎使用
z-index，优先考虑用order或grid-area来控制视觉层级。 - 遇到“明明z-index更高却还被盖”的诡异情况，排查顺序应该是：先看Computed样式里的「Stacking Context」和「z-index」状态，再检查DOM的位置顺序。
说到底，真正卡住人的往往不是z-index该填多大的数字，而是它到底有没有进入一个可以相互比较的“竞技场”。下次再怀疑z-index失效，别慌，打开开发者工具，先看「Stacking Context」提示，再沿着祖先节点逐级点开Computed样式检查——你会发现，90%的问题都出在第三层或第四层父元素上，而不是你正在埋头苦调的那个class里。
