4. CSS动画与硬件加速：让浏览器真正“跑”起来
做前端动画，最怕什么？掉帧。明明代码逻辑没问题，动画就是卡卡的。我早年做过一个数据可视化大屏项目，折线图过渡动画在 Chrome 上丝般顺滑，换到某款国产浏览器直接变成幻灯片。排查到最后，问题出在——我触发了浏览器的重排（Reflow）。
这一章，我们就来聊聊怎么让 CSS 动画真正利用 GPU 加速。说白了，就是告诉浏览器：“别用 CPU 慢慢算了，交给 GPU 去并行处理。”
4.1 为什么偏偏是 transform 和 opacity？
你可能会问：CSS 属性那么多，为什么只有这两个能享受硬件加速？
答案其实很简单：它们不会触发重排（Reflow）和重绘（Repaint）。
浏览器渲染一个元素，大致走这么几步：
- JavaScript：执行脚本，修改样式
- Style：计算样式
- Layout：计算几何位置（重排）
- Paint：绘制像素（重绘）
- Composite：合成图层
当你改变 width、height、left、top 这些属性时，浏览器必须重新走 Layout → Paint → Composite 三步。而 transform 和 opacity 的变化，浏览器直接跳过 Layout 和 Paint，只走 Composite。这一步，就是交给 GPU 来做的。
核心结论：transform 和 opacity 的动画，浏览器只做合成（Composite），不做布局和绘制。这是硬件加速的基石。
我记得有一次接手一个老项目，里面大量使用 left 做位移动画。我改成 transform: translateX() 后，帧率直接从 20fps 飙到 60fps。改动就一行代码，效果天差地别。
4.2 will-change：提前告诉浏览器“我要动”
will-change 这个属性，说白了就是给浏览器打预防针。
你想想看：浏览器默认不知道你接下来要动画哪个元素。它只能在你改变属性的那一刻，临时决定要不要创建合成层。这个决策本身就有开销。
will-change 的作用就是提前声明：“这个元素我马上要动画了，你先给它准备好合成层。”
/* 提前告知浏览器 */
.element {
will-change: transform, opacity;
}
/* 动画结束后记得移除，否则会浪费内存 */
.element.animated {
will-change: auto;
}我的习惯：只在动画开始前加上 will-change，动画结束后立即移除。不要在整个页面生命周期里一直挂着，否则 GPU 内存会被白白占用。
4.3 触发 GPU 合成层的条件
除了 transform 和 opacity，还有哪些情况会让浏览器创建合成层？我整理了一张表：
| 触发条件 | 说明 | 注意点 |
|---|---|---|
transform 动画 |
使用 translate/scale/rotate 等 | 避免同时改变其他布局属性 |
opacity 动画 |
透明度变化 | 0 到 1 之间性能最佳 |
will-change |
显式声明即将变化的属性 | 用完即弃，不要常驻 |
filter 动画 |
模糊、亮度等滤镜效果 | 性能开销较大，慎用 |
position: fixed |
固定定位元素 | 浏览器会自动提升为合成层 |
video / canvas |
多媒体元素 | 默认就有合成层 |
z-index 高于合成层 |
层叠上下文提升 | 可能引发层爆炸 |
我曾经踩过的坑：为了追求性能，我给页面上十几个元素都加了 will-change: transform。结果页面滚动变得异常卡顿。为什么？因为每个元素都创建了独立的合成层，GPU 内存被撑爆了。合成层不是越多越好，够用就行。
4.4 合成层的工作原理
为了让你更直观地理解，我画了一张流程图：
4.5 实战：如何写出硬件加速友好的动画
光说不练假把式。我们来看一个实际例子：
/* ❌ 错误写法：触发重排 */
.box-bad {
position: absolute;
left: 0;
top: 0;
transition: left 0.3s ease;
}
.box-bad.active {
left: 100px;
}
/* ✅ 正确写法：只触发合成 */
.box-good {
transform: translateX(0);
transition: transform 0.3s ease;
will-change: transform;
}
.box-good.active {
transform: translateX(100px);
}我的经验：如果你需要同时改变位置和大小，尽量用 transform 的 translate 和 scale 组合，不要分开写 left 和 width。一次合成比两次合成要快得多。
4.6 避坑指南：合成层不是万能药
嗯，这里要注意几个容易翻车的地方：
- 层爆炸：每个合成层都会占用 GPU 内存。移动端尤其敏感，我见过一个页面创建了 30 多个合成层，直接导致浏览器崩溃。
- will-change 滥用：不要给所有元素都加上
will-change。只给即将动画的元素加，动画结束立刻移除。 - transform 的 3D 陷阱：
translateZ(0)确实能强制开启硬件加速，但也会创建合成层。用多了照样卡。 - filter 动画：
filter虽然也能触发合成层，但它的计算开销比transform大得多。能用opacity模拟的，就别用filter。
我曾经翻过的一个车：在移动端 H5 页面里，我给一个弹窗动画加了 filter: blur(10px) 作为背景模糊效果。结果在低端安卓机上，弹窗打开时整个页面卡了将近 1 秒。后来换成用 opacity 配合半透明背景，流畅多了。
4.7 小结
这一章的核心就三句话：
- 用
transform和opacity做动画，别用left、top这些布局属性。 will-change是好东西，但别滥用，用完就收。- 合成层不是越多越好，够用就行。