HTML动画最吃CPU的三类是box-shadow和filter（触发软件渲染）、top/left位移动画（触发layout→paint→composite全流程）、大量元素同时运行动画；应优先使用transform和opacity并开启will-change优化。
HTML动画本身不直接“要求”CPU占用，但它会显著影响CPU（和GPU）的负载，尤其在复杂或低效实现时。是否卡顿、掉帧、发热，取决于动画类型、浏览器渲染机制和设备能力，而不是你写了 animation 还是 requestAnimationFrame 这个动作本身。
哪些HTML动画最吃CPU
不是所有动画都一样。以下三类最容易拉高CPU使用率：
-
box-shadow、filter（如blur()、drop-shadow()）在元素频繁重绘时，会触发软件渲染，强制CPU参与合成，尤其在滚动或缩放中叠加使用时，CPU占用飙升明显 - 用
top/left+position: relative/absolute驱动位移动画——每次变化都触发 layout → paint → composite 全流程，浏览器无法启用硬件加速，纯靠CPU计算样式和绘制 - 大量元素同时运行动画（比如 100+ 个
div各自执行transform: rotate()），即使单个开销小，叠加后主线程压力剧增，requestAnimationFrame回调堆积，CPU持续满载
怎样写动画才不容易拖垮CPU
核心原则：让浏览器尽可能走 GPU 加速路径，避开重排（reflow）和重绘（repaint）。
- 优先用
transform和opacity动画——它们是 CSS 中仅有的两个能触发“合成层”（compositing layer）且无需重排重绘的属性 - 对需要动画的元素显式开启硬件加速：加
will-change: transform（仅在动画前设置，动画结束建议移除，避免长期占用纹理内存） - 避免在
scroll或resize事件里直接修改样式；改用transform: translateY()+getBoundingClientRect()计算偏移，再交由requestAnimationFrame批量更新 - 用 Chrome DevTools 的 Rendering 面板勾选 “Paint flashing” 和 “FPS meter”，直观看到哪些区域在频繁重绘、帧率是否稳定在 60fps
一个对比源码：高CPU vs 低CPU写法
下面两个例子功能相同（元素左右平移），但底层行为差异巨大：
立即学习“前端免费学习笔记（深入）”；
<!-- ❌ 高CPU写法：触发 layout + paint -->
<div id="bad" style="position: relative; left: 0px;">Bad</div>
<script>
let pos = 0;
function animateBad() {
pos = (pos + 2) % 400;
document.getElementById('bad').style.left = pos + 'px';
requestAnimationFrame(animateBad);
}
animateBad();
</script>上面代码每帧都修改 left，导致浏览器必须重新计算布局（layout），再重绘（paint），最后合成（composite）——全链路压 CPU。
<!-- ✅ 低CPU写法：只触复合成 -->
<div id="good" style="transform: translateX(0px);">Good</div>
<script>
let pos = 0;
function animateGood() {
pos = (pos + 2) % 400;
document.getElementById('good').style.transform = `translateX(${pos}px)`;
requestAnimationFrame(animateGood);
}
animateGood();
</script>这个版本只改 transform，浏览器可将其标记为独立合成层，后续只需 GPU 移动图层，CPU 基本不参与。
CPU占用不是唯一瓶颈，别只盯着它看
真正影响用户体验的，往往是帧率稳定性、内存泄漏、以及动画中断响应延迟。有些动画在 CPU 占用只有 15% 时仍卡顿——因为主线程被长任务阻塞，requestAnimationFrame 回调被推迟；也有些动画 CPU 占 40%，但帧率稳在 60fps，用户完全无感。实际优化时，先打开 DevTools 的 Performance 面板录制一段动画，看主线程火焰图里是不是有长任务、是否有 forced reflow、合成层是否合理，比单纯盯 CPU 数字靠谱得多。
