drop-shadow() 触发重绘而非合成，是卡顿主因；它走滤镜管线、无法硬件加速，而 box-shadow + transform 等可 GPU 加速，动画中应避免动态修改 filter 参数、多层阴影及 transition: all。
filter: drop-shadow() 触发重绘而非合成，是卡顿主因
很多人以为 drop-shadow() 和 box-shadow 一样轻量，实际它底层走的是滤镜管线，每次动画帧都要对整个元素做像素级模糊计算。Chrome DevTools 的“Rendering”面板勾选“Paint flashing”后，能看到整块区域高频闪烁——这不是过渡慢，是每帧都在重绘。
对比之下：box-shadow 只需合成层叠加，GPU 可直接处理；而 filter: drop-shadow() 无法被硬件加速，尤其在中低端 Android 或旧 iOS 上，60fps 直接掉到 20–30fps。
- 避免在
@keyframes中动态修改filter: drop-shadow()的参数（如模糊半径、偏移量） - 若必须用阴影动画，优先改用
box-shadow+transform模拟位移感 - SCSS 中不要写
@include shadow-animate($blur: 0px, $blur: 12px)这类插值生成多帧 filter —— 编译后仍是 filter 动画，无效
SCSS mixin 自动生成的多层 box-shadow 在动画中放大性能问题
常见做法是用 SCSS 循环生成 5–8 层 box-shadow 模拟立体阴影，例如：
@mixin deep-shadow {
box-shadow: 0 2px 4px rgba(0,0,0,0.1),
0 4px 8px rgba(0,0,0,0.12),
0 8px 16px rgba(0,0,0,0.14);
}
问题在于：这些阴影在 transition 或 animation 中一旦参与变化（比如 hover 时扩大所有偏移值），浏览器会为每一层重新计算布局+绘制，而不是复用合成层。实测 3 层以上就明显拖慢首帧渲染。
立即学习“前端免费学习笔记（深入）”；
- 动画中只让
box-shadow的color或opacity变化（这两项可 GPU 加速） - 偏移和模糊半径必须动？改用单层
box-shadow+transform: translateZ(1px)配合will-change: transform - SCSS mixin 里避免用
@for生成超过 3 层阴影用于动画场景
transition: all 导致无关属性被强制加入动画管线
很多 SCSS 组件库的通用 transition 写法是 transition: all 0.3s ease，但 all 会把 box-shadow、filter、background-position 全部拉进动画队列。哪怕你只改了 transform，浏览器也得为其他属性准备回滚快照，内存占用翻倍。
- 动画元素务必显式声明要过渡的属性：
transition: box-shadow 0.3s ease, transform 0.3s ease - SCSS 中别用
@mixin hover-transition($props...)泛化传参——编译后容易漏掉关键属性或混入冗余项 - 检查编译后 CSS，确认没有类似
transition: all 0.3s, opacity 0.3s这种重复声明（后者会被前者覆盖，但解析开销仍在）
伪元素阴影动画未触发独立合成层
为绕过主元素的 filter 卡顿，有人用 ::before 画阴影再动画它。但若没手动建层，伪元素仍和父元素共用一个图层，动画时整块重绘。
正确姿势是给伪元素加 transform: translateZ(0) 或 will-change: transform，强制提升为独立合成层。SCSS 中容易忽略这点，尤其当 mixin 封装了伪元素逻辑时。
- 所有用于动画的伪元素，必须包含
content: ""+position: absolute+transform: translateZ(0) - 不要在 mixin 里只写
box-shadow而不配合成层声明——编译后就是纯 CPU 渲染 - iOS Safari 对
will-change支持不稳定，稳妥起见用transform: translateZ(0.001px)替代
真正卡顿的从来不是 SCSS 本身，而是编译后 CSS 是否触发了浏览器的合成优化路径。阴影动画的性能分水岭，就在「是否让 GPU 接管」这一行代码上——少一个 transform，多一层重绘。
