mix-blend-mode不是上色工具，而是要求元素与背后内容真实重叠、同属一个层叠上下文且背后有可混合像素；<img>无反应因它常处顶层，下方无有效底色或父容器触发了新层叠上下文。
mix-blend-mode 不是“给元素上色”的开关，它只在元素与背后内容真实重叠、同属一个层叠上下文、且背后有可参与混合的像素时才起作用。直接加在 <img> 或文字上却没反应？八成是混合链断了。
为什么 mix-blend-mode 加在 <img> 上完全没反应？
根本原因：图片自己就是最顶层，下面没有“背后内容”可混——父容器是纯白或透明背景？等于拿一张图跟白纸做乘法，multiply 也还是白。mix-blend-mode 混的是当前元素和它 z 轴正下方所有已渲染内容（包括父容器背景、兄弟元素、甚至 body 的 background-color），不是和它自己的 background-image 混。
- 检查父容器是否设置了可见背景：
background: linear-gradient(#ff0000, #00f)或background-color: #333 - 确认父容器没触发新层叠上下文：删掉
transform、opacity: 0.99、isolation: isolate这类属性 - 别把图片当
background-image用：如果用了background: url(...) #fff，那该配的是background-blend-mode，不是mix-blend-mode
让文字和图片真正融合的最小结构
必须保证文字 DOM 在图片 DOM 的上方，且两者处于同一层叠上下文。最简可靠写法：
<div class="blend-container"> <img src="photo.jpg" alt=""> <h2 class="blend-text">标题</h2> </div>
.blend-container 设固定尺寸和相对定位；.blend-text 用 position: absolute 叠上去，并确保没被 z-index 隔离。
立即学习“前端免费学习笔记（深入）”；
- 文字颜色建议用极值：
color: #000或color: #fff，中间灰度色（如#666）在difference下会崩对比度 - 避免给文字加不透明背景块：半透色块会先自身合成，再参与混合，结果偏灰、发雾
- 移动端 iOS 14–15 中，动画里动态改
mix-blend-mode值会静默失效——改成固定模式 + 动态调background-color或opacity
multiply / screen / overlay 效果差异怎么看？
别靠名字猜，它们是确定的数学公式：
-
multiply：逐通道相乘（Cb × Cs），越暗的底色，压得越深；适合叠加阴影色块 -
screen：反相→相乘→再反相（1 − (1−Cb) × (1−Cs)），越亮的底色，提得越明显；适合泛光、高光染色 -
overlay：自动分区域——底色暗区走multiply，亮区走screen；对真实照片最自然，但纯色块上易过曝
实操建议：先用 background-color: #ff0000 盖一层红底，再试不同模式，观察灰阶图上哪些区域变暗、哪些变亮、哪些几乎不变。
移动端兼容性和性能陷阱
iOS Safari 和部分 Android WebView 对层叠上下文极其敏感。轮播容器加了 transform: translateZ(0)、卡片用了 backdrop-filter、甚至只是写了 position: relative; z-index: 1，都可能切断混合链，导致文字/图片“悬空”混合失败。
- 修复方法：在混合元素的**直接父容器**上加
isolation: isolate，强制它成为独立上下文，让子元素能读取真实背后的颜色 - 性能上，
mix-blend-mode触发整块区域全像素重绘，比纯transform慢一个数量级；滚动中带混合的文字极易在中低端安卓机掉帧 - 动画中禁用
mix-blend-mode切换，改用background-blend-mode（仅限多背景图之间）或缩小混合区域范围（用isolation: isolate+transform: translateZ(0)单独包裹）
最常被忽略的一点：Chrome DevTools 的 “Paint flashing” 功能（Rendering → Paint flashing）能直接告诉你有没有发生重叠绘制——没高亮，说明压根没混合，别调样式，先查层叠关系。
