mix-blend-mode在ios safari等移动端白屏，根本原因是浏览器激进提层后主动关闭混合通道；应改用translatez(0.1px)或scale(1.0001)轻量提层，配合isolation: isolate隔离及禁用backdrop-filter，并为无支持环境提供渐变fallback。
mix-blend-mode 在某些移动端浏览器（尤其是 iOS Safari 和旧版 Android WebView）导致白屏，不是因为属性写错，而是浏览器在创建合成层时**主动关闭了混合通道**——它把元素提成了“不参与混合的独立图层”，背后内容被当作透明黑/白底处理，结果就是整块区域变空、发白或发黑。
为什么 Safari + will-change: transform 一组合就白屏
Safari 对 will-change: transform 的实现非常激进：只要声明，立刻创建一个带 alpha 隔离的 GPU 图层，并默认禁用该图层与底层内容的混合能力。DevTools 的 Layers 面板里能看到对应图层标注为 “Composited layer (noblending)”。这种行为在 iOS 16 及更早、macOS Safari 15.6–16.3 中尤为普遍。
- 常见触发组合：
position: fixed+transform: translateZ(0)+will-change: transform+mix-blend-mode - 禁用
will-change后白屏消失，但动画可能卡顿 → 说明问题出在“提层策略”，而非混合本身 - Chrome/Firefox 不会这样，所以本地开发看不出来，真机一跑就崩
Android WebView 4.4–6.0 根本不解析 mix-blend-mode
这些版本的系统 WebView 基于裁剪版 Blink，mix-blend-mode 解析逻辑被直接移除。它不会报错，也不会 fallback，而是静默忽略整条声明 —— DevTools 里能看到你写的 mix-blend-mode: screen，但 computed 值永远是 normal，页面毫无反应。
- @supports 检测不可靠：Android 6.0 WebView 中
@supports (mix-blend-mode: multiply)可能返回true，但渲染仍为normal - 别浪费时间调
isolation或transform：那些是给“已实现但被截断”的场景用的，这里连入口都没加载 - 华为 EMUI、小米 MIUI 等定制 ROM 普遍滞后，实测断点集中在 Android 4.4–7.0
真正有效的绕过方式：轻量提层 + 隔离 + fallback
目标是让元素进 GPU 合成层，又不切断混合链；同时覆盖无支持环境。
- 替换
will-change: transform：改用transform: translateZ(0.1px)或transform: scale(1.0001)，Safari 不会因此关闭混合通道 - 必须加
isolation: isolate到混合元素的**直接父容器**：否则父级的opacity: 0.99、backdrop-filter或position: relative; z-index: 1会意外切断混合链 - 禁用
backdrop-filter：Safari 15.4 之前两者共存必崩，16.4+ 才稳定，生产环境应避免同时启用 - fallback 方案优先用渐变叠加：
background-image: linear-gradient(rgba(0,0,0,0.4), rgba(0,0,0,0.4)), url("main.jpg");，比background-blend-mode更可靠
最容易被忽略的是：白屏问题从来不是单一原因，而是“提层策略 + 层叠上下文 + 引擎缺失”三者叠加的结果。真机调试时，别只看 computed 值是否生效，要观察渲染结果是否真实变化 —— 那才是唯一可信的信号。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
