box-shadow 和 filter 是安卓低端机掉帧的头号元凶，尤其在 android 5–7 webview 中无法进入 gpu 合成线程，导致动画从 60fps 骤降至 20fps 以下；应改用伪元素渐变、预渲染阴影图或媒体查询降级等零/低开销方案替代。
box-shadow 和 filter 是安卓低端机掉帧的头号元凶，不是“有点慢”，而是直接让动画从 60fps 掉到 20fps 以下——尤其在 Android 5–7 的 WebView 中，它们根本进不了 GPU 合成线程。
为什么 box-shadow 动画在低端安卓上特别卡
它不是加个阴影那么简单：浏览器得为每个帧实时生成模糊纹理、做高斯卷积、叠加绘制，全程走 CPU 的 Paint 阶段，transform 和 will-change 完全无效。更糟的是，blur-radius 每增加 2px，显存占用翻倍；父容器设了 overflow: hidden 时，某些安卓 WebView 会直接放弃图层合并，整块重绘。
- 实测：在 MT6737（Android 6.0）上，单个
box-shadow: 0 4px 12px rgba(0,0,0,0.15)就让动画掉帧 15–20% - 绝对不要在
@keyframes中动画blur-radius或spread-radius—— 每一帧都在触发重绘 - 用 Chrome DevTools 的
Rendering → Paint flashing看绿色是否集中在阴影区域，就能实锤是不是它拖后腿
filter 动画（尤其是 blur/drop-shadow）为何比 box-shadow 还难搞
filter: blur() 在中低端安卓上基本等于“CPU 渲染邀请函”；drop-shadow() 虽比 box-shadow 更可能进合成器，但在 Android 5–7 WebView 中大概率被忽略或退化为 CPU 绘制。而且，filter 和 transform 同时存在时，很多旧版 WebView 会拒绝升层，导致整条动画降级。
- 别写
will-change: filter—— 它不生效，还可能干扰图层管理 - 想强制 GPU 加速？可用
transform: translate3d(0, 0, 0)配合filter，但仅限单个、即将动画的元素，且动画完必须清空transform - 用 DevTools 的
Layers面板搜索含filter的元素，看是否真生成了独立绿框图层；没绿框＝还在主线程跑
怎么替掉 box-shadow 和 filter 而不牺牲视觉
关键不是“不用”，而是用零运行时开销或低开销方式模拟相同效果。静态场景优先预渲染，动态场景用渐变或滤镜降级兜底。
- 卡片/列表项阴影：改用伪元素 +
linear-gradient，比如::after { background: linear-gradient(to bottom, rgba(0,0,0,0.1), transparent); height: 4px; } - 需要模糊感但设备老旧：用媒体查询降级，
@media (max-width: 480px) and (-webkit-device-pixel-ratio: 1) { .card { filter: none; } } - 必须动态适配？
filter: drop-shadow()只在 Chrome 84+ / Safari 13.1+ 可合成，旧环境 fallback 到伪元素方案 - 背景阴影统一用
background-image: url("shadow-sprite.png")，切好带透明度的 PNG，无计算成本
如何快速验证和定位问题根源
别靠猜，用 DevTools 直接看渲染流水线哪一环堵死了。
- 打开
Rendering → Paint flashing，触发动画，持续大面积绿色＝Paint 阶段过载，重点查box-shadow、filter、border-radius是否参与动画 - 切到
Layers面板，搜索关键词box-shadow或filter，看对应元素有没有独立图层；没有＝浏览器连抢救都放弃了 - 在
Performance面板录制动画，筛选Paint事件，点开耗时长的记录，看Call Stack是否出现paint+shadow相关调用
真正麻烦的不是“不知道该换什么”，而是动画里混着一个 box-shadow 或 filter，其他所有 transform 和 opacity 优化全白搭——浏览器不会报错，只会默默把整条动画拉回 CPU 渲染。动手前，先打开 Layers 面板确认绿框是否真实存在。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
