z-index: 9999 未生效主因是元素未定位或父级创建了层叠上下文；需确保 position 为 relative/absolute/fixed/sticky，且检查祖先是否触发 stacking context（如 opacity<1、transform、filter 等）。
z-index: 9999 没生效，不是数字小，而是它压根没参与层叠计算，或被锁死在某个父级“小房间”里了。
元素没定位，z-index 直接被浏览器忽略
这是最常被跳过的前提。z-index 对 position: static（默认值）完全无效，哪怕你写了 z-index: 9999，DevTools 的 «Computed» 面板里 z-index 仍显示为 auto，position 也还是 static。
- 打开 Chrome DevTools → 选中被遮挡元素 → «Computed» 面板搜索
position，确认计算值是relative、absolute、fixed或sticky - 临时加
position: relative（不位移、不影响布局），如果遮挡立刻消失，就坐实是这问题 - 特别注意响应式断点：桌面端设了
position: fixed，移动端媒体查询里漏写，就会退成static
父级悄悄创建了层叠上下文（stacking context）
即使目标元素已定位、z-index 计算值也正确，只要它的任意一个祖先（不一定是直接父级）触发了层叠上下文，整个子树就被关进独立空间——z-index: 9999 只能跟同房间里的兄弟比，够不到外面的导航栏或弹窗。
- 触发层叠上下文的常见属性：
opacity小于 1（opacity: 0.99也触发）、transform不是none（包括transform: translateZ(0)、scale(1)）、filter不是none（哪怕filter: blur(0)）、will-change: transform、isolation: isolate、position: fixed或sticky且z-index不为auto - 用 DevTools 快速定位：选中被遮挡元素 → «Layout» 标签页看
Stacking context是否为Yes；点击右侧Show stacking context，高亮区域就是“玻璃罩”边界 - 逐级点击父节点，在 «Computed» 里搜
transform、opacity、filter，第一个非默认值就是源头
z-index 数值再大也突破不了父容器的“天花板”
子元素的 z-index 只决定它在父容器内部的顺序，对外它只继承父容器在整个页面中的层级位置。比如父容器 z-index: 10，子元素写 z-index: 9999，它依然压不过另一个 z-index: 20 的同级容器。
立即学习“前端免费学习笔记（深入）”；
- 修复方向不是堆数字，而是提升“关住它”的那个父容器本身的
z-index（例如设为z-index: 1050） - 如果父容器必须保留
transform（如动画需要），就给它同步加position: relative和足够高的z-index - 验证是否真由层叠上下文导致：把目标元素（比如弹窗或下拉菜单）剪切出来，用 JS 直接
document.body.append()，再测试层级——如果这时能正常显示，100% 是父级层叠上下文问题
移动端和第三方组件的特殊限制
iOS Safari 对 body 和 html 极其敏感：html { transform: translateZ(0) } 这种写法会在整个页面顶层建一个强上下文，把所有后续 z-index 全锁死在里面。地图 SDK、视频播放器等第三方组件也常暗中触发 transform 或 opacity，却不暴露样式。
- Tailwind 用户注意：
zIndex必须在tailwind.config.js中以对象语法定义（如{ 'modal': '60' }），改完要重启 dev server；z-[999]动态拼接在构建时不会被扫描 - 调试时别只盯着自己写的
z-index，打开 Chrome 的 «Rendering» 面板 → 勾选 «Show layers panel» → 切到 «Layers» 标签页，直接看到每个层叠上下文对应的 DOM 节点 - 真正决定渲染顺序的不是你写的数字，而是浏览器实际生成的层叠结构；靠肉眼猜或盲目调高数值，效率极低
