mix-blend-mode在部分浏览器中背景变黑，是因元素在错误层叠上下文里与纯白/透明背景执行multiply计算所致；其只与“元素背后内容”混合，无视自身background-color或opacity，若父容器为空、白色或含opacity:0.99等隐式创建新层叠上下文的属性，即触发全黑。
mix-blend-mode 在部分浏览器中背景变黑，不是样式写错了，而是混合对象错位或合成层被意外隔离——你看到的“全黑”，其实是元素在错误的层叠上下文里跟纯白/透明背景做了 multiply 计算。
mix-blend-mode 跟谁混合？不是你设的 background-color
它只跟“元素背后的内容”混合，完全无视自身 background-color: rgba(0,0,0,0.3) 或 opacity。如果你给文字加了 mix-blend-mode: multiply，但它的直接父容器是空的、白色或透明的，那它就只能跟那个纯白背景算乘法 → 白 × 任何色 = 原色，但黑 × 白 = 黑，所以文字区域大面积发黑。
- 常见诱因：父容器没设背景图/色，或用了
opacity: 0.99（强制创建新层叠上下文） - 更隐蔽的情况：父容器有
transform: translateZ(0)、filter: blur(1px)或position: sticky，也会隐式隔离混合目标 - 验证方法：Chrome DevTools → More Tools → Layers，看该元素是否被单独分层且“背后一片空白”
Safari 和旧 Android WebView 中 computed 值恒为 normal
Android 4.4–6.0 WebView 和 Safari 7–8 根本没实现 mix-blend-mode 解析逻辑，CSS 声明被 parser 直接忽略。DevTools 里 mix-blend-mode 的 computed 值永远显示 normal，哪怕你写了 screen。这不是渲染异常，是功能缺失。
-
@supports (mix-blend-mode: multiply)在 Android 6.0 WebView 中可能返回true，但渲染仍是normal—— 检测不可信 - 别浪费时间调
isolation或transform，这些对“未实现”的场景无效 - 真机测试必须覆盖 iOS 8.x、Android 4.4（如三星 Galaxy S5）、macOS Safari 7.1
opacity 是最危险的触发器
只要任意祖先元素用了 opacity（哪怕 opacity: 0.99），整个子树就被提进新层叠上下文，mix-blend-mode 只能跟那个祖先的背景混合。如果祖先背景是 #fff，又用了 multiply，结果就是大面积黑块。
- 替代方案：
color: rgba(0, 0, 0, 0.7)控制文字透明度，background-color: rgba(255, 255, 255, 0.1)控制蒙层，避开opacity属性 - 动画透明度时，用
transform: opacity+will-change: opacity，但注意 Safari 旧版仍可能提层 - 若父容器必须模糊或动效，务必在其上显式加
isolation: isolate
mix-blend-mode + overflow: hidden 导致裁剪与混合冲突
overflow: hidden 会提前裁剪渲染上下文，而 mix-blend-mode 需要访问被裁剪区域外的完整像素才能计算混合结果。两者共存时，浏览器要么放弃混合（回退到 normal），要么绕过裁剪（内容溢出）。
- 典型场景：轮播卡片容器设了
overflow: hidden，内部标题加mix-blend-mode: screen→ 标题变黑或消失 - 解决路径：移除
overflow: hidden，改用clip-path或结构隔离（如用position: absolute+ 父容器overflow: hidden包裹图片层，文字层独立） - 切勿在混合元素自身设
overflow: hidden，这是硬冲突
真正难调的从来不是 multiply 还是 screen，而是它在哪一层、跟谁混合、有没有被浏览器悄悄“移出舞台”。先打开 Layers 面板，看清层在哪，再决定加 isolation 还是提 transform —— 否则所有调试都在错的方向上打转。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
