z-index数值再大也无效的常见场景是元素不在同一层叠上下文中：父元素未创建层叠上下文，或自身处于更低层级的上下文中，导致子元素z-index仅在内部生效，无法与外部元素比较。
z-index数值再大也无效的常见场景
z-index不是全局层叠开关，它只在同一个层叠上下文（stacking context）内起作用。你给一个元素设了z-index: 9999，但它父容器没创建层叠上下文，或者父容器自己被另一个更外层的z-index更低的层叠上下文“罩住”，那这个9999就完全不参与最终排序。
典型现象：position: relative 的子元素加了 z-index: 999，却盖不住隔壁兄弟元素；或者弹窗明明设了高z值，却被页头导航栏挡住。
- 触发层叠上下文的常见方式：父元素有
position且非static+z-index值不为auto；或有opacity 、<code>transform、filter、will-change等属性 - 一旦父元素创建了层叠上下文，子元素的
z-index只跟同级兄弟比，不再跟外部其他上下文里的元素比 - 浏览器渲染时先按层叠上下文分组，再在每组内部按
z-index排序 —— 所以跨组比较毫无意义
为什么父元素加了position但z-index还是不起作用
关键在于父元素的 z-index 值是否有效。如果父元素 position 是 static（默认值），哪怕写了 z-index: 999 也完全被忽略 —— CSS规范明确要求：只有 position 为 relative、absolute、fixed 或 sticky 时，z-index 才生效。
- 检查父元素是否真的应用了非
static的position（用开发者工具看 computed 样式，别只信 source） -
z-index: auto和没写一样，不会创建层叠上下文；必须是具体数字（包括0）才可能触发 - 父元素若本身处于另一个低层级的层叠上下文中（比如被
opacity: 0.99的祖先影响），它的整个子树都会被“压扁”到那个层级里
移动端 Safari 中 z-index 表现异常的原因
iOS Safari 对层叠上下文更敏感，尤其在使用 transform 或 will-change 时，会隐式创建独立的合成层，导致 z-index 行为和桌面 Chrome 不一致。常见表现：下拉菜单在 iPhone 上被轮播图遮挡，即使菜单父容器 z-index 更高。
立即学习“前端免费学习笔记（深入）”；
- 避免对父容器滥用
transform: translateZ(0)或will-change: transform，除非真需要 GPU 加速 - 如果必须用
transform，记得同时显式设置z-index并确保其父级也构成清晰的层叠上下文 - 测试时务必真机调试 —— iOS 模拟器和桌面 Safari 的合成策略不同，容易误判
用开发者工具快速定位 z-index 失效根源
不要靠猜。Chrome / Edge / Safari 的 Elements 面板里，选中元素后点右上角三个点 → “Show stacking order”，能直接看到当前元素所属的层叠上下文链路，以及它在整个页面中的实际绘制顺序。
- 如果某元素旁边标着 “Stacking context root”，说明它是某个上下文的起点，它下面所有子元素都困在这个范围内
- 对比两个打架的元素，看它们是否在同一个上下文里；如果不是，往上逐级查谁创建了隔离
- 注意
opacity、filter这类“隐形触发器”，它们没有z-index却能强行建上下文
真正卡住的往往不是 z-index 该设多少，而是没意识到自己早被关进了一个看不见的层叠盒子里。
