最耗电的是filter: blur()和drop-shadow()，因默认cpu渲染致全层重绘；contrast()、opacity()较轻量；will-change: filter易引发图层爆炸；需用devtools layers面板验证gpu加速是否生效。
因为 filter 动画（尤其是 blur()、drop-shadow()）在多数移动端浏览器中默认走 CPU 渲染路径，每帧都要重绘整层像素，持续拉高 CPU 负载——这不是“动画太炫”，而是浏览器被迫用 CPU 做高斯卷积或阴影扩散。
哪些 filter 属性最耗电
不是所有 filter 都一样危险，关键看是否触发全层重绘：
-
filter: blur(1px)在 Android 5–7 WebView 中就足以让 60fps 掉到 35fps；实测 MT6737 芯片上，blur(4px)单元素就能让 CPU 占用率飙到 90%+ -
filter: drop-shadow()比box-shadow更易进 GPU（Chrome 84+、Safari 13.1+），但 iOS 上模糊值 > 8px 仍会回退 CPU，且不支持 spread -
filter: contrast(110%)、opacity(0.9)属轻量级，现代浏览器基本可合成，耗电可控 -
filter: url(#svg-filter)或残留的 SVG 滤镜引用会持续占用 GPU 纹理，即使动画已停，手机仍在发热
为什么加 will-change: filter 反而更烫
它不是加速开关，而是内存预分配指令。旧版移动端浏览器无法预判参数变化，只会盲目建层：
- 全局写
* { will-change: filter }→ 图层爆炸，低端安卓机显存迅速耗尽，直接 OOM 卡死 - 列表项批量加
will-change: filter→ 每个元素都占一个离屏缓冲区，内存带宽吃紧时白屏 - 动画中途频繁切换
blur(0px) → blur(6px) → blur(0px)→ 图层反复创建销毁，GPU 上下文切换开销翻倍
怎么确认滤镜真进了 GPU
CSS.supports('filter', 'blur(1px)') 返回 true ≠ 实际启用 GPU 加速。必须靠运行时验证：
- Chrome DevTools → Layers 面板 → 搜索目标元素 → 看是否独立显示为
Filter Layer，而非 “Shared with ancestor” - 勾选 Rendering → “Layer Borders” → 有绿色边框才代表被提升；若无边框，说明仍在主线程重绘
- iOS Safari 15.4 之前，
backdrop-filter必须配合background-color: rgba(255,255,255,0.1)才生效，否则声明被静默跳过
最容易被忽略的一点：动画期间 JS 读取 getBoundingClientRect() 或 offsetTop，哪怕只调一次，也会强制同步布局，让原本跑在 GPU 的 filter 动画瞬间破防——CPU 开始逐帧重排重绘，手机立刻升温。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
