Android WebView（4.4–6.0）因内核裁剪未实现mix-blend-mode，@supports检测不可靠；替代方案应采用多层background-image静态合成，用PNG+rgba渐变确保兼容。
mix-blend-mode 在多数 Android WebView（尤其是 4.4–6.0）中根本不会执行，不是写法错，是引擎压根没实现。 它在 Chrome for Android 35+ 有基础支持，但系统 WebView（比如微信内嵌、QQ 浏览器、老版 UC）长期停留在 WebKit/Blink 旧分支，mix-blend-mode 被静默忽略——DevTools 里能看到声明，Computed 值却是 normal，页面毫无反应。
为什么安卓 WebView 不认 mix-blend-mode
Android 4.4（KitKat）首次引入 Chromium 内核 WebView，但只带了 Blink 的极简子集；后续厂商定制（如华为 EMUI、小米 MIUI）又大量裁剪 CSS 高级特性。实测关键断点：
- Android 4.4–5.1：WebView 完全不解析
mix-blend-mode，连@supports都返回false - Android 6.0：部分机型（如 Nexus 5X）可识别但渲染异常，文字常变纯黑/白块
- Android 7.0+：依赖厂商是否更新 WebView APK，国产 ROM 普遍滞后 2–3 年
更麻烦的是，mix-blend-mode 和 isolation: isolate 在旧引擎里是耦合失效的——就算你加了 isolation，只要父容器有 opacity: 0.99 或 transform，整个链路就崩。
用 background-blend-mode 替代时的致命陷阱
很多人想退而求其次用 background-blend-mode（作用于单元素多层背景），但它在安卓上同样脆弱：
立即学习“前端免费学习笔记（深入）”；
- Safari 15.4 前不支持，而 Android WebView 多数基于更老 WebKit，直接跳过整条声明
- 混用
linear-gradient和url()时，部分安卓浏览器（如三星 Internet 4.x）会把渐变层渲染成纯黑或纯白块 -
@supports (background-blend-mode: multiply)在 Android 6.0 WebView 中返回true，但实际渲染仍失败——检测不可靠
所以别写 fallback 检测逻辑，它骗不了真机。
真正可用的背景图层叠方案
放弃运行时混合，改用静态合成 + 多层 background-image 模拟效果，兼容性拉满：
div.title-overlay {
/* 第一层：主图 */
background-image: url("main.jpg");
/* 第二层：叠加纹理/渐变（PNG 透明通道保留） */
background-image:
linear-gradient(rgba(0,0,0,0.2), rgba(0,0,0,0.2)),
url("main.jpg");
/* 降级：只加载 fallback.jpg，无混合 */
background-image: url("fallback.jpg");
}关键点：
- 所有
background-image声明按从下到上顺序书写，浏览器取最后一个有效值 - 纹理层必须是 PNG（带 Alpha），不能是 JPG；渐变层用
rgba()而非hsla()，旧引擎对后者支持更差 - 避免混用 SVG 和位图作为背景层，某些安卓 WebView 对 SVG 渲染上下文处理不同步，导致图层错位
移动端 Safari 与安卓 WebView 的共性盲区
哪怕你绕开了 mix-blend-mode，还有两个隐藏雷区：
-
backdrop-filter和mix-blend-mode共存？Safari 15.4+ 才稳定，安卓 WebView 全系不支持，写了等于没写 - 用
transform: translateZ(0)强制提层来“修复”混合？在 Android 5.0 WebView 中反而触发渲染 bug，文字闪烁或消失 - 真机调试时别信 Chrome DevTools 的模拟，必须用 Android 4.4/5.1 实机 + Weinre 或原生 WebView 日志看实际渲染结果
最省事的解法往往最可靠：Figma 里把标题和背景图合成一张 PNG，用 background-image 直接引入。高清屏补 2x 图，响应式用 JS 根据 window.devicePixelRatio 切换 style.backgroundImage，比折腾混合模式少掉三帧、少踩五个坑。
