filter滤镜是低端安卓机掉帧主因，因默认cpu渲染，blur()和drop-shadow()尤甚；需替换为预渲染图、伪元素渐变或canvas模糊，并禁用冗余提升与残留声明。
filter 滤镜是低端安卓机掉帧的隐形主力，不是“加了加速就没事”，而是默认走 CPU 渲染，blur() 和 drop-shadow() 尤其危险——中低端设备上一开就掉帧，必须砍、必须替、必须控。
为什么 filter 在低配机上特别卡
blur(2px)、drop-shadow(0 2px 4px rgba(0,0,0,0.1)) 这类操作在 Android 5–7 WebView 或旧版 Chrome 中，根本不会进 GPU 合成器；浏览器只能用 CPU 做高斯模糊或阴影卷积，每帧都重绘整块区域。实测在 MT6737 芯片设备上，单个 filter: blur(4px) 就能让 60fps 动画跌到 35fps 左右。iOS Safari 15.4 之前对 backdrop-filter 的支持也极弱，开了等于白开。
哪些 filter 属性能勉强跑得动
不是所有 filter 都一样慢，关键看是否能触发合成层：
-
filter: opacity(0.9)和filter: contrast(110%)属于轻量级，现代浏览器基本可合成，风险较低 -
filter: drop-shadow()比box-shadow更易进 GPU（Chrome 84+、Safari 13.1+），但不支持 spread，且模糊值 > 8px 时 iOS WebKit 仍会回退到 CPU -
filter: blur()是性能黑洞，哪怕blur(1px)在低端安卓上也常触发全层重绘；backdrop-filter: blur(10px)在 iOS 上必须配合background-color: rgba(255,255,255,0.1)才生效，否则直接失效
替代方案比硬扛更实际
与其调参数挣扎，不如换思路：
- 毛玻璃效果不用
backdrop-filter，改用预渲染半透图：background-image: url("glass-bg.png")，零运行时开销 - 卡片阴影不用
filter: drop-shadow()，改用伪元素渐变：::after { background: linear-gradient(to bottom, rgba(0,0,0,0.08), transparent); height: 4px; } - 需要动态模糊？用 Canvas 缩放 + 均值模糊：先将图缩到 1/3 尺寸，再做半径为 2 的均值采样，比 CSS
blur()快 5–8 倍，且可控降质 - 悬停滤镜动画禁止单独过渡
blur()，改用opacity+contrast组合：transition: opacity 0.2s, filter 0.2s，并确保 hover 状态下blur()值 ≤ 1px
真要保留 filter，必须避开三个坑
很多团队试过“加 transform: translateZ(0) 就行”，结果更卡——问题不在写法，而在滥用：
- 别给每个列表项加
will-change: filter：浏览器无法预判参数变化，会提前分配大量内存，安卓低端机容易 OOM - 父容器已用
transform: translate3d(0,0,0)提升，子元素再加translateZ(0)是冗余提升，无收益反增开销 - 动画过程中频繁切换
filter值（如blur(0px) → blur(6px) → blur(0px)）会触发图层反复创建销毁，应限制为“开/关”两级状态
最常被忽略的一点：你以为关掉了 filter 就安全了，但只要页面里还存在一个未移除的 filter: blur(0px)，某些安卓 WebView 仍会把它当“潜在高成本操作”持续监控——真正要删的是整条声明，不是只调数值。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
