滤镜性能差因强制CPU计算与离屏缓冲：blur()和drop-shadow()在旧设备上不进GPU，单个blur(4px)可使动画从60fps跌至35fps；backdrop-filter更危险，需处理背后滚动区域，易致白屏、撕裂、帧率跌破15fps。
因为 filter 不是纯合成操作，它强制浏览器做逐像素计算并分配高分辨率离屏缓冲区，而旧版或低配设备的渲染管线根本扛不住。
blur() 和 drop-shadow() 是性能黑洞
这两类滤镜在 Android WebView 5–7、iOS Safari 15.4 之前、低端 MT6737/MT6757 芯片设备上基本不进 GPU 合成器，浏览器只能用 CPU 做高斯卷积或阴影采样。实测单个 filter: blur(4px) 就能让 60fps 动画跌到 35fps。
-
blur(1px)在部分安卓 WebView 中仍会触发全层重绘，不是“小值就安全” -
drop-shadow()比box-shadow更重——它要先渲染一个新图层再合成，且 iOS WebKit 对模糊半径 > 8px 会回退到 CPU -
filter: url(#svg-filter)各浏览器回退策略不一，Chrome 可能硬解，Safari 直接跳过
will-change: filter 并不能救性能
它只是提前告诉浏览器“这个元素的 filter 值会变”，从而预分配合成层和着色器。但它无法改变滤镜本身的计算开销，反而容易引发副作用。
- 写在 hover 前 100ms 内、动画结束立刻设回
auto才有意义；全局写* { will-change: filter }会导致图层堆积、内存暴涨 - 在 iOS Safari 上几乎无效，某些 Chrome 版本甚至因强制升层加剧文字糊感
- 如果页面里还残留未移除的
will-change: filter声明，DevTools Layers 面板里可能看不到明显问题，但 GPU 纹理上传已持续占用
backdrop-filter 在移动端更危险
它不只是模糊当前元素，而是要提取“背后整个滚动区域”的内容做离屏处理。一旦用在列表项、position: sticky 导航栏或 overflow 容器内，就会触发多层嵌套离屏缓冲区。
- Chrome Layers 面板中看到 “Filter Layer” 单独占一行，且纹理尺寸是元素本身的 2–4 倍（Retina 屏下更夸张）
- 滚动时出现白屏延迟、边缘撕裂、帧率跌破 15fps，基本就是 backdrop-layer 数量超标（>8～10 层）
-
transform: translateZ(0)在 backdrop 场景下大概率更卡——它让浏览器预分配一个大纹理，结果背后内容还在滚动，导致每帧都要重传整个缓冲区
真正卡顿的点往往不在“用了什么滤镜”，而在“谁在什么时候继承了它”。父容器加了 filter: blur(8px)，子文字节点就自动进模糊管线；一个 backdrop-filter 用在 overflow-y: auto 的弹窗里，背后整页 DOM 都得被截、缩、糊、传——这些细节比参数调优更容易被忽略。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
