z-index失效的根本原因是元素分属不同层叠上下文，彼此z-index不参与比较；需检查父级是否因opacity、transform等触发新上下文，并确保目标元素position非static。
z-index设再大也盖不住外部元素，是因为它根本没进同一个“赛场”
z-index不是全局排名系统，而是一场局部选举。只要两个元素不在同一个层叠上下文（stacking context）里，它们的z-index值就互不比较——哪怕一个是z-index: 9999，另一个是z-index: 1，也完全可能被后者盖住。
典型现象：弹窗组件明明写了z-index: 2147483647，却仍被顶部导航栏遮挡；检查发现导航栏父容器设置了opacity: 0.99，而弹窗挂载在另一个带transform: translateZ(0)的卡片内部——两者各自创建了独立层叠上下文，浏览器按 DOM 渲染顺序决定谁在上，而非子元素的z-index。
- 根层叠上下文（即
生成的那个）只对“无任何祖先触发上下文”的元素生效；一旦中间某个父级满足触发条件，它就成了新上下文的根 - 两个元素若分属不同上下文，最终堆叠顺序由它们各自上下文根节点在**父级上下文中的层级**决定，和子元素
z-index无关 -
z-index值相同的元素，在同一上下文中按 HTML 顺序后出现者覆盖前者；跨上下文则完全不参与此规则
哪些父级样式会悄悄把子元素“关进小黑屋”
这些属性只要非初始值，就会让该元素变成层叠上下文根节点，子元素的z-index从此只能在它内部起作用：
-
opacity小于 1（opacity: 0.99就够了） -
transform不为none（包括transform: translateZ(0)、scale(1)、rotate(0.0001deg)） -
filter不为none（哪怕只是filter: blur(0.1px)） -
will-change设为transform、opacity等值 isolation: isolate-
position: fixed或position: sticky（即使没写z-index）
特别注意：transform: scale(1) 和 translateZ(0) 常被当“硬件加速 hack”滥用，但它们会静默创建上下文，导致内部下拉菜单、tooltip 全部失效。
立即学习“前端免费学习笔记（深入）”；
怎么快速定位是哪个父级在“拦路”
别改z-index，先查层叠上下文链路。目标元素被盖住，说明它和遮挡者之间至少有一个“隔离父级”。
- 在 Chrome DevTools 的 Elements 面板中选中目标元素，右侧 Computed 标签页拉到底，看 “Stacking context” 是否显示 “Yes”
- 逐级点击父节点，每点一个都看这个字段是否突然变成 “Yes” —— 重点盯那些你没意识到会触发上下文的元素（比如只写了
opacity: 0.99的 wrapper） - 临时注释掉可疑样式（如
filter或transform），观察遮挡是否消失；恢复后可尝试给该父级加z-index: 0（显式创建上下文但保持默认层级）再测试 - 如果必须保留视觉效果（如淡入动画），那就得让遮挡者和目标元素进入同一上下文：提升它们最近的共同祖先的
z-index，而不是狂堆子元素值
position: static 是 z-index 的硬性开关，不是可选项
z-index对position: static元素完全无效——这是最常被忽略的前提。哪怕你给一个<div>写了<code>z-index: 9999，只要没配position: relative（或absolute/fixed/sticky），这个值就是摆设。
- 检查 DevTools Styles 面板中
position的最终计算值，确认不是static -
float不会激活定位，不能让z-index生效；即使写了position，也要防被后续样式（如重置 CSS）覆盖回static - 内联元素（如
<span></span>）加position: relative后，建议同步加display: inline-block或block，否则可能因盒模型异常影响层叠表现
真正难的不是调数字，而是看清哪一层在管事——层叠上下文看不见、摸不着，却决定了所有z-index有没有资格参选。一旦父级触发了它，子元素再高的值也只是在自己房间喊口号。
