mix-blend-mode会强制创建新层叠上下文，使元素脱离父级堆叠层，z-index仅在自身上下文中生效，无法与兄弟元素横向比较；混合顺序由dom渲染顺序决定，而非z-index。
mix-blend-mode 会强制创建新的层叠上下文
这不是“改变”z-index顺序，而是直接绕过它——mix-blend-mode只要被声明（哪怕值是normal），浏览器就会为该元素创建独立的层叠上下文（stacking context）。这意味着它和兄弟元素不再处于同一混合平面，z-index只在它自己的上下文内有效，无法再与父容器里的其他元素横向比高低。
常见翻车场景：
- 两个兄弟都设了
mix-blend-mode: multiply，但其中一个z-index更高却盖不住另一个——因为它们根本不在同一个堆叠层里- 父容器加了
transform: scale(1)，子元素又设mix-blend-mode，结果双重隔离，混合彻底失效- 想用z-index控制混合先后顺序？没用。混合顺序由DOM渲染顺序决定：后出现的元素，才跟前面已绘制的内容混合
混合生效的前提是“能穿透到背后”，而层叠上下文会切断穿透链
mix-blend-mode不是本地滤镜，它必须能“看到”背后的像素（父背景、兄弟元素、body色等）。一旦父级触发了新层叠上下文（比如opacity: 0.99、isolation: isolate、filter: blur(1px)），子元素就只能跟这个新上下文的“底板”混合——而那个底板往往就是透明或纯色，导致混合看起来像没生效。排查建议：
- 临时移除父容器所有可能触发层叠上下文的样式：
opacity、transform、filter、will-change、isolation - 用
CSS.supports('mix-blend-mode', 'multiply')确认支持性，别依赖devtools里样式没划掉就以为生效 - 检查背后是否有真实内容：如果
mix-blend-mode: screen用在白色背景上，效果就是“看不见”，不是bug
position: fixed 元素在 Safari 上混合行为异常
Safari 16.4 之前，
mix-blend-mode+position: fixed组合会导致滚动残留、白屏或错位，这不是兼容性检测能绕过的硬伤。即使现在新版 Safari 支持，也仍需注意：- fixed 元素的“背后”内容在滚动时动态变化，浏览器可能缓存旧帧参与混合
- 某些 iOS 设备上，GPU 加速未启用时，混合区域会闪烁或跳变
- 真机测试不可替代：模拟器里正常 ≠ iPhone 12/SE3 上不崩
真正难调的是混合与 z-index 的隐式冲突
你以为调高 z-index 就能让 A 盖住 B 再一起混合？错。实际是：A 和 B 各自混合，但 A 混合的是它“下面”的内容（可能是 body 背景），B 混合的也是它“下面”的内容（可能是 A 的底层部分）——除非你让它们视觉重叠且同属一个层叠上下文，否则它们压根不参与彼此的混合计算。
安全做法只有两个：
- 把要混合的元素提一级，确保它们和共同背景（如
或一个无隔离的<div>）在同一层叠上下文 <li>用 DOM 顺序代替 z-index 控制混合先后：后写的元素自然覆盖先写的，也自然跟先写的混合</li> <p>最易被忽略的一点：mix-blend-mode 的“背后”永远是渲染顺序上更早、且未被隔离的内容；它不认 z-index，只认 DOM 位置和层叠上下文边界。</p> </div>
- 父容器加了
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
