mix-blend-mode仅在元素与背后内容视觉重叠、同属一个层叠上下文、且背后有可混合内容（如背景色/图或兄弟元素）时生效；不适用于background-image和无内容伪元素，也非直接上色工具。
mix-blend-mode 能实现 Photoshop 级别的图层混合效果，但**它不是给单个元素“上色”的工具，而是让重叠元素之间发生像素级颜色运算**。直接加在 <img> 或文字上却没反应？大概率是没满足混合前提。
mix-blend-mode 不生效的三个硬性条件
它只在以下三者同时成立时才起作用：
- 元素必须与其他内容存在**视觉重叠**（z-index、position、文档流顺序都得对）
- 混合元素和其背后的“底物”（backdrop）必须处于**同一个层叠上下文**——父容器不能有
isolation: isolate、transform、opacity 等触发新 stacking context 的属性 - 背后必须有**可参与混合的内容**：可以是父容器背景（颜色/渐变/图片）、更早渲染的兄弟元素，甚至 body 的 background-color
常见翻车点：<div>
<img src="a.jpg"><p style="max-width:90%">text</p>
</div> 中，如果 <p></p> 没设 position: relative 或 z-index，它可能根本没盖在图片上；或者父 <div> 加了 <code>opacity: 0.99，就悄悄切断了混合链。
multiply / screen / overlay 的实际表现差异
别靠名字猜效果，它们本质是数学公式：
-
multiply：逐通道相乘（Cb × Cs），深色区域变暗，浅色区域影响小；适合压暗照片高光、叠加阴影色块 -
screen：反相相乘再反相（1 − (1−Cb) × (1−Cs)），亮色更突出；适合提亮局部、模拟泛光 -
overlay：自动判断明暗——暗区用multiply，亮区用screen；对真实照片最自然，但纯色块上容易过曝
实操建议：先用 background-color: #ff0000 盖一层固定色块，再试不同模式，观察同一张灰阶图上哪些区域变暗、哪些变亮、哪些几乎不变。半透明元素参与混合时，会先合成自身 alpha，再与背景算混合值，结果常比预期更“灰”。
iOS Safari 和低端 Android 的兼容性陷阱
mix-blend-mode 在 iOS 14–15 上问题最多：动画中突然失效、will-change: transform 导致混合层跳变、某些 GPU 配置下直接禁用。Android Chrome 虽好些，但千元机仍可能掉帧或闪烁。
- 避免在
@keyframes里动态切换mix-blend-mode值——改用固定模式 + 动态调background-color或opacity - 绝对不要给混合元素加
will-change: transform，它会强制创建独立合成层，彻底断开混合 - 降级方案别只写
@supports (mix-blend-mode: difference)，iOS 7–8 会误报支持；更稳妥的是：@supports (mix-blend-mode: difference) and (not (-webkit-appearance: none))
为什么不能用 background-blend-mode 替代 mix-blend-mode
background-blend-mode 只管一个元素自身的多层背景（比如 url(a.jpg), linear-gradient(#f00, #f00)），它**完全不感知文字、子元素或父级背景**。想让 <p></p> 文字适配外部容器背景色？必须用 mix-blend-mode，因为它的混合对象是“当前元素内容”与“它下方整个堆叠上下文”的最终合成结果。
最容易被忽略的一点：混合效果高度依赖底层内容的实际像素值。一张 PNG 透明区域、CSS 渐变的过渡带、甚至 subpixel rendering 下的文字边缘，都会让混合结果产生细微但关键的偏差——真机调试时务必关掉系统色彩管理，否则 iOS 的 P3 色域补偿会让 difference 模式输出意外的灰阶。
