z-index无效的首要原因是元素position为static，必须设为relative/absolute/fixed/sticky才生效；其次需排查祖先是否创建了层叠上下文（如opacity<1、transform不为none等）；iOS Safari对transform更敏感，需为触发transform的父容器显式设置position和z-index。
z-index写了但完全没反应，先查position是不是static——浏览器压根不读你的z-index值，只要元素的position是static（默认值），它就自动被排除在层叠计算之外。这不是“效果弱”，而是“不参与”。
目标元素的position是不是static？
这是最常被忽略的前提：z-index只对position为relative、absolute、fixed或sticky的元素起作用。
- 常见误操作包括：只写
z-index: 999，忘了加position: relative - 用JS动态添加样式时，只改
z-index，漏掉同步设置position - 误以为
display: flex或grid子项能靠父容器定位“继承”层级——其实子项自己必须显式声明position
快速验证方法：打开Chrome DevTools，选中目标元素，在「Computed」面板里搜position，确认最终值不是static；临时加一行position: relative，看z-index是否立刻生效。
某个祖先元素是否意外创建了层叠上下文？
即使position设对了，z-index也可能被锁死在局部范围——只要某个祖先元素满足以下任一条件，它就创建了新的层叠上下文（stacking context），子元素的z-index只能在它内部比大小：
立即学习“前端免费学习笔记（深入）”；
-
opacity小于1（哪怕opacity: 0.999） -
transform不为none（包括看似无害的transform: translateZ(0)、scale(1)） -
filter不为none（哪怕filter: blur(0)） -
will-change: transform或will-change: opacity isolation: isolate-
position: fixed或sticky且z-index非auto
调试建议：在DevTools Elements面板中逐级点击父节点，右侧面板「Layout」标签页留意「Stacking context」是否突然变成Yes；临时注释掉可疑父级的transform或opacity，看遮挡是否立刻消失。
iOS Safari下transform + z-index组合特别容易翻车
iOS Safari（尤其≤16.6）对transform创建层叠上下文极其激进：哪怕只是transform: translateZ(0)，它就立刻建盒子；而Chrome可能忽略。更麻烦的是，如果这个带transform的父容器没显式设position和z-index，它的子元素层级就容易错乱。
- 正确做法不是堆子元素的
z-index，而是修复父容器：给触发transform的父容器加上position: relative和z-index: 0（注意：z-index: 0必须配position才生效） - 避免只靠
translateZ(0)做硬件加速却不设z-index，这在Safari下等于埋雷 - 测试时务必真机验证，模拟器有时无法复现该问题
响应式断点中transform或opacity被激活导致失效
很多响应式动画会加transform: translateZ(0)或opacity: 0.99强制GPU加速，但只要值不是none，就触发新层叠上下文。哪怕只在@media (max-width: 768px)里启用一行，父容器立刻变成堆叠上下文根节点。
- 用DevTools切到对应断点，在「Computed」面板搜
transform，看是否从none变成了具体值 - 所有涉及
position变更的媒体查询，必须成对修改：position+z-index - 用
getComputedStyle(el).getPropertyValue('z-index')在控制台验证断点生效后的实际值，注意auto和0的语义差异：z-index: 0会强制创建新上下文，z-index: auto不会（前提是元素已定位）
真正难的不是算清哪个断点该写多少，而是每次改完媒体查询，都要往上多看两层DOM，确认那个刚被激活的transform或opacity没把你需要突出的元素关进盒子。
