z-index失效首要原因是元素position为static，需确认computed值非static；其次父级触发层叠上下文（如opacity<1、transform非none等）会隔离子元素z-index，须用DevTools逐级检查stacking context并调整定位或提级DOM。
z-index写了却没用，先看元素有没有定位
直接失效的最常见原因：元素 position 还是 static（默认值）。哪怕你写了 z-index: 999，浏览器会当它不存在。
检查方式：打开 DevTools → 选中该元素 → 右侧「Computed」面板里找 position，确认它是不是 relative、absolute、fixed 或 sticky。别信源码里写了就完事，得看 computed 值是否生效。
-
position: relative最安全——不脱离文档流，又能激活z-index -
position: absolute要小心父容器是否已定位；否则top/left会相对于 viewport 计算，容易错位 -
position: fixed自带层叠上下文，且默认z-index: auto，需显式设值才可控
被“关小房间”了：父级悄悄建了层叠上下文
即使你元素本身定位正确、z-index 也生效，只要它的某个祖先（不一定是直接父级）触发了层叠上下文，整个子树就被锁死在那个“房间”里——z-index: 999 只能跟同房间里的兄弟比，根本够不到外面的导航栏或弹窗。
这些属性一出现，就等于给父级加了玻璃罩：
立即学习“前端免费学习笔记（深入）”；
-
opacity: 0.99（哪怕只差 0.01） -
transform: translateZ(0)、scale(1)、rotate(0deg)等任何非none值 -
filter: blur(0)、grayscale(0%)等非none值 -
will-change: transform或will-change: opacity isolation: isolate-
z-index: 0（注意：不是auto，0 会创建新上下文）
特别提醒：z-index: 0 和 z-index: auto 行为完全不同——前者建“房间”，后者不建。
怎么快速揪出是哪个父级在“截胡”
别靠猜，用 Chrome DevTools 直接定位：
- 选中被遮挡的元素 → 右侧面板「Computed」→ 搜索
stacking context，如果显示 This element establishes a stacking context，说明它自己就是边界；往上点父节点，找到第一个也标这个的，就是问题源头 - 更直观：打开「Rendering」面板 → 勾选 Show layers panel → 切到「Layers」标签页，每个层叠上下文对应一个 DOM 节点，点击就能高亮
- 临时删掉可疑父级的
opacity、transform、filter，看遮挡是否立刻消失——这是最快验证手段 - 把目标元素剪切出来，直接挂到
<body>下测试；如果这时能正常显示，基本坐实是层叠上下文问题
数值堆再大也没用，关键是层级归属
z-index: 9999 不是万能钥匙。它只在一个层叠上下文内部有效；跨上下文时，比的是父级的“房间高度”，不是你的数字。
- 第三方组件（地图 SDK、视频播放器）可能暗中用了
transform或opacity，你调自己的z-index完全无效 - 移动端 Safari 对
transform和will-change更敏感，容易多建合成层，导致行为和桌面不一致 - 设计系统里通常有预设层级变量，比如
--z-nav: 100、--z-modal: 1050；导航栏设z-index: 101就够，没必要堆到 9999 - 如果必须保留父级的
opacity或动画效果，就把需要置顶的元素（如 tooltip、dropdown）用position: fixed提出来，挂到<body>下，再手动计算top/left和滚动偏移
真正麻烦的从来不是数字大小，而是你不知道自己写的 z-index 正在跟谁比——先搞清它属于哪个“房间”，再决定是拆墙、抬房，还是换房间。
