z-index失效的根本原因是父级创建了层叠上下文，将子元素z-index限制在内部；isolation: isolate是无副作用的显式解法，但需配合position: relative和z-index使用。
为什么 z-index 再大也压不住兄弟元素
根本原因不是值不够，而是目标元素的某个父级悄悄创建了层叠上下文，把它的 z-index “锁死”在内部。比如父容器加了 opacity: 0.99、transform: scale(1) 或 filter: blur(0)，哪怕只是视觉上没变化，也会触发新上下文——子元素再设 z-index: 9999，也只跟同级兄弟比，出不了这个“结界”。
常见现象包括：下拉菜单被歌单面板盖住、Tooltip 在轮播图里消失、Modal 遮罩层透出底下的卡片背景。Chrome DevTools 的 Computed 面板搜 stacking context，第一个标有 “This element establishes a stacking context” 的祖先就是罪魁祸首。
isolation: isolate 是最干净的显式解法
isolation: isolate 不改变透明度、不强制硬件加速、不引发字体发虚，是唯一无副作用的显式创建新层叠上下文的方式。但它只划边界，不自动提升层级——你必须同时给该容器加 position: relative 和明确的 z-index（比如 z-index: 100），否则它在外部仍默认为 0 层级，照样被盖。
兼容性注意点：
- Safari 14 及更早需加前缀：
-webkit-isolation: isolate -
isolation: auto是默认值，无效；没有isolation: on这种写法 - 别和
mix-blend-mode混用，除非真需要混合隔离
替代方案对比：opacity/transform/filter 哪个坑最多
它们都能触发层叠上下文，但副作用差异极大：
-
opacity: 0.99：改了透明度，哪怕 0.01 的差值也可能破坏设计一致性 -
transform: translateZ(0)：强制 GPU 加速，Safari 中易导致will-change行为错乱，字体渲染变糊 -
filter: blur(0)：看似无害，但某些旧版 Chrome 会误判为“真实滤镜”，触发额外绘制开销
而 isolation: isolate 什么也不画、不缩放、不模糊，纯逻辑隔离，DevTools 的 «Layers» 面板能清晰看到它成了上下文根节点。
DOM 位置和 z-index 谁优先级更高
当多个 position: fixed 元素同属根层叠上下文（即都没被父级截断），HTML 顺序决定默认堆叠：后写的元素天然在前写的上方。所以 z-index: 100 写在前面的导航栏，可能被后面一个 z-index: 10 的弹窗盖住。
实操建议：
- 关键 UI（顶部栏、全局 Modal、Tooltip 容器）统一挂到
document.body底部，紧邻
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
