html动画本身不直接占用cpu，但实际运行中常引发cpu活跃，关键取决于实现方式：raf中避免强制布局、css动画优选transform/opacity、canvas需优化绘制逻辑并暂停非可视区域动画。
HTML 动画本身不直接“占用 CPU”，但实际运行中几乎必然引发 CPU 活跃，关键看你怎么写、用什么方式驱动、是否触发重排重绘。
requestAnimationFrame 触发的 JS 动画吃 CPU 吗
会，但可控。只要你在 requestAnimationFrame 回调里做轻量计算（比如只更新 transform 或 opacity），浏览器通常能走合成层（compositor thread），主线程压力小；一旦在里面读取 offsetTop、getComputedStyle 或频繁操作 innerHTML，就会强制同步布局（forced layout），CPU 占用立刻飙升。
- 避免在 rAF 里访问任何会触发 layout 的属性（
offsetHeight、scrollLeft等） - 优先用 CSS 变量 +
will-change: transform提前升层，减少 JS 干预 - 用 Chrome DevTools 的 “Rendering” 面板勾选 “Layout Shift Regions” 和 “FPS Meter”，实时观察是否掉帧或意外 layout
CSS 动画（@keyframes）为什么有时也拉高 CPU
不是动画本身吃 CPU，而是你动错了属性。CSS 动画只有作用于 transform 和 opacity 时才大概率走 GPU 合成；若动画目标是 width、height、left、top 或 background-color，每次帧都会触发 layout → paint → composite 全流程，CPU 和内存都扛不住。
- 检查动画是否被降级：打开
chrome://gpu，确认 “Compositing” 显示 hardware accelerated - 用
transform: translateX(0)强制创建新图层，比position: relative; left: 10px更安全 - 避免在动画中切换
display或大量增删 class，这会打断合成器流水线
Canvas 动画卡顿，是 CPU 还是 GPU 问题
大概率是 CPU 瓶颈，尤其在未启用离屏渲染或未做脏矩形优化时。Canvas 2D 上下文所有绘制命令都由 CPU 执行并提交到 GPU，如果每帧执行 clearRect + 全量重绘 + 文字测量 + 图片解码，CPU 很快满载；WebGL 虽走 GPU，但 JS 层的矩阵计算、顶点更新、状态切换仍压主线程。
- 用
createImageBitmap预解码图片，避免drawImage时阻塞 - 对静态内容缓存为
OffscreenCanvas（需 Worker 支持）或canvas.toDataURL()后转为Image - 禁用
canvas.getContext('2d', { willReadFrequently: true })——除非真要读像素，否则它会禁用硬件加速
真正容易被忽略的是：动画逻辑是否在非可视区域持续运行。比如轮播图组件没做 IntersectionObserver 停止、Canvas 动画没监听 visibilitychange 事件暂停，这些都会让 CPU 白干活。别只盯着“怎么动得更顺”，先确保“该不动的时候真停了”。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
