z-index失效的根本原因是父元素创建了新的层叠上下文，导致子元素的z-index仅在该上下文中生效；常见触发属性包括opacity<1、transform≠none、filter≠none、will-change、isolation:isolate及position+z-index非auto。
z-index失效是因为父元素创建了新的层叠上下文
直接说结论：z-index在子元素上设得再高，只要它的某个祖先元素触发了层叠上下文（比如设置了opacity、transform、filter、will-change，或position: fixed/absolute + z-index非auto），那这个子元素的层级就只在这个“小世界”里有效，跨不出去。
常见现象：两个弹窗，一个用Vue动态挂载到body，另一个在modal组件内部；后者明明z-index: 9999，却盖不住前者——八成是modal的父容器带了transform: translateZ(0)或者opacity: 0.99。
- 检查目标元素向上最近的、有层叠上下文的祖先，用浏览器开发者工具的“Computed”面板看
contain、transform、opacity等属性是否非默认值 - 临时移除疑似父级的
transform或opacity，确认是否恢复覆盖——这是最快定位手段 - 不要只盯着子元素改
z-index，它再大也破不了父级的“结界”
哪些CSS属性会悄悄创建层叠上下文
不是只有z-index能建层叠上下文。这些属性一旦出现，就会让该元素变成“新层叠根”，它下面所有z-index都重新计数，且无法和外部同级元素比高低：
-
position: relative/absolute/fixed/sticky+z-index不为auto -
opacity小于1（哪怕0.999） -
transform值不为none（包括translateZ(0)、scale(1)这种看似无害的） -
filter不为none -
will-change包含transform、opacity等值 isolation: isolate
特别注意：transform: scale(1)和transform: translateZ(0)常被当作“触发硬件加速”的惯用写法，但它们会静默创建层叠上下文，导致内部弹窗层级失控。
立即学习“前端免费学习笔记（深入）”；
修复方案：要么拔掉父级上下文，要么统一提升到同一上下文
不能只修子元素，得看整体结构。两种主流解法，选哪个取决于你能不能动父级样式：
- 如果父容器加
transform或opacity只是为兼容或动画过渡，且非必须，直接删掉——最干净 - 如果必须保留（比如要实现淡入动画），就把需要“突围”的元素（如
tooltip、dropdown）用position: fixed+z-index提出来，挂到body下（注意处理top/left定位和滚动偏移） - 若多个模块共用一个父容器，且都需高优先级显示，不如把该父容器自身设为高
z-index，让它整体“抬高”，比在内部疯狂堆z-index更可控
示例：一个带transform: translateY(0)的卡片内有select下拉菜单，菜单始终被遮挡。解决方案不是给select加z-index: 99999，而是把select的popper实例挂到body，并确保其z-index高于卡片父容器的层级。
调试时别信“z-index数字越大越好”这个直觉
浏览器渲染时，层叠顺序是按“层叠上下文树”逐级比较的，不是全局比数字。一个z-index: 2的元素，只要它在根上下文里，可能比另一个z-index: 999但在三层嵌套层叠上下文里的元素更靠前。
- 打开 Chrome DevTools → Elements → 右键目标元素 → “Show layers”（需开启Rendering面板的Layers选项），能直观看到层叠上下文边界
- 用
getComputedStyle(el).getPropertyValue('z-index')确认实际计算值，避免auto被误认为0 - 移动端尤其容易踩坑：
transform: translateZ(0)在iOS Safari中创建层叠上下文的行为比桌面端更严格
真正麻烦的从来不是z-index设多少，而是你根本没意识到某一层父元素已经把它锁进了自己的小房间。
