z-index无效的根本原因是目标元素未参与层叠计算或被父级层叠上下文限制；需检查position是否为static、父级是否因opacity/transform/filter等创建了堆叠上下文，并调整对应父级的z-index或移除触发属性。
z-index设再大也盖不住，根本不是数值问题，而是目标元素压根没参与层叠计算，或者被某个父级“关进小房间”了——这个房间叫层叠上下文（stacking context），子元素再高的z-index也只能在房间里当老大。
目标元素的position是不是static？
浏览器对position: static（默认值）的元素完全忽略z-index，哪怕写成z-index: 999999也无效。这不是“效果差”，是直接不进层叠队列。
- 打开 Chrome DevTools → 选中被遮挡元素 → «Computed» 面板搜
position，确认最终值不是static - 临时加一行
position: relative（不位移、不影响布局），看遮挡是否立刻消失 - JS 动态插入时容易只改
z-index，漏掉同步设position；display: flex或grid的子项也不能靠父容器“带进去”，必须自己显式声明position
哪个父级在悄悄创建堆叠上下文？
子元素的 z-index 再高，也出不去它直属的堆叠上下文。真正拦住你的，往往是一个加了 opacity: 0.999、transform: translateZ(0) 或 filter: blur(0) 的父 div。
- 选中被遮挡元素 → «Layout» 标签页看
Stacking context是否为Yes - 逐级点父节点，在 «Computed» 里搜
opacity、transform、filter、will-change、isolation—— 任意一个非默认值，就是源头 - 特别注意：
overflow: hidden+position: relative（哪怕z-index: auto）也会强制创建堆叠上下文，且还会裁掉内容
z-index: 0 和 z-index: auto 效果完全不同
z-index: 0 只要元素已定位，就会创建新堆叠上下文；z-index: auto 不会（前提是已定位）。很多人以为加个 0 很安全，结果它正是把子元素锁死的“结界开关”。
立即学习“前端免费学习笔记（深入）”；
- 别只狂堆子元素的数字。如果父容器已经建了“结界”，子元素的
z-index: 9999只是在它内部当老大，对外无效 - 真正要调的是那个“关住它”的父容器本身的
z-index（比如设成z-index: 1050） - 如果父容器加
transform是为了过渡动画且可删，直接移除比堆数字干净十倍；必须保留时，给该父容器加position: relative+ 合理z-index
调试时最容易被忽略的复杂点
页面里可能嵌套多层堆叠上下文，而 DevTools 的 «Layout» 面板只显示当前元素是否在上下文中，不自动指出“上一级是谁”。得手动逐层点上去查，漏一层就修不对。最常卡住人的，是第 4 层或第 5 层祖先上那个看似无害的 transform: scale(1) 或 opacity: 0.999。
