mix-blend-mode生效需同时满足三个条件：视觉重叠、同层叠上下文、背后有可混合内容；缺一不可，常见失效原因包括未真正叠盖、层叠上下文被opacity/transform等切断、背景无有效色彩，且必须在直接父容器设isolation: isolate。
mix-blend-mode写了但没效果，八成是三个条件断了一个
它不是“开关式”属性，而是依赖视觉重叠、同层叠上下文、背后有可混合内容三者同时成立。缺一不可，写对了也白搭。
常见断链点：
- 元素没真正盖在背景上：比如
<p>在文档流里，父容器又没设position: relative，z 轴根本没叠上去 - 层叠上下文被意外切断：父容器加了
opacity: 0.99、transform: translateZ(0)或backdrop-filter，混合对象变成“透明空气” - 背后没东西可混：父容器只有纯白背景，
multiply算出来全黑，screen几乎不变，看起来像没动
移动端失效不是兼容性问题，是 isolation 没加对
iOS Safari 和多数 Android WebView（尤其 4.4–6.0）下，mix-blend-mode 静默失效的主因不是不支持，而是混合链被上游层叠上下文截断——isolation: isolate 必须加在混合元素的直接父容器上，加在 body 或 wrapper 上无效。
注意：
立即学习“前端免费学习笔记（深入）”；
- 即使父容器已有
transform或filter，isolation: isolate仍需手动声明，不继承 -
will-change: transform会强制创建独立合成层，彻底断开混合，必须避免 - 文字颜色慎用中间灰度值（如
#666），推荐纯黑#000或纯白#fff，否则混合结果不可控
@supports 检测不可信，真机测试才是唯一标准
@supports (mix-blend-mode: multiply) 在 Android 6.0 WebView 中可能返回 true，但渲染仍是 normal。这不是 bug，是检测机制和渲染路径脱钩。
实操建议：
- 只把
@supports当作“可选增强”开关，绝不用于关键视觉逻辑 - 必须覆盖真机测试：Android 4.4–6.0 WebView（三星、华为旧机型）、iOS 8.x Safari
- 服务端判断优先解析 User-Agent 中的 OS 和 WebView 版本，而非依赖 JS 检测
别试图动画 mix-blend-mode，浏览器根本不允许插值
mix-blend-mode 是离散属性，写 transition: mix-blend-mode 0.3s 或放进 @keyframes 里，结果只会硬切，DevTools 还会标黄警告 transition ignored。
正确做法是固定一个模式（如 overlay），再动画它的输入项：
- 用
opacity变化控制混合权重：从0.7 → 1实现“呼吸式融合” - 用
transform: translateX()移动前景层，让它与静止背景持续发生像素级重叠变化 - 绝对不要用 JS 定时器挨个切换
multiply→screen→overlay，仍是跳变
最易被忽略的一点：所有启用 mix-blend-mode 的容器，必须显式加 isolation: isolate——这不是可选项，是混合生效的硬性前提。position 或 z-index 都不能替代它。
