canvas动画cpu飙高主因是requestanimationframe中每帧遍历万元素数组、全量重绘、频繁getimagedata/putimagedata及高开销合成模式；css动画仅在纯transform/opacity且硬件加速时低cpu；lottie选错渲染器（如canvas）或移动端无offscreencanvas支持亦致cpu过载。
HTML 动画本身不直接占用 CPU —— 真正吃 CPU 的是背后的 JavaScript 执行、Canvas 绘制逻辑或 CSS 属性频繁重算。
Canvas 动画为什么 CPU 占用飙到 90%+
你写的 requestAnimationFrame 循环里如果每帧都做以下操作，CPU 就会拉满：
- 遍历一个几万元素的数组（比如
colorMap）并逐个调用ctx.fillStyle+ctx.fillRect - 没做脏区检测，每帧全量重绘整个画布（哪怕只变一个像素）
- 在
draw函数里反复调用ctx.getImageData或ctx.putImageData—— 这俩是同步阻塞操作 - 用了
ctx.shadowBlur或ctx.globalCompositeOperation = 'multiply'等高开销合成模式
实测：一个 1024×768 的 Canvas，每帧执行 5000 次 fillRect（无缓存），Chrome 主线程 Scripting 时间占比常超 70%，Performance 面板一眼可见。
CSS 动画和 transform 的 CPU 友好边界
只要满足以下全部条件，CSS 动画基本不推 CPU：
- 只动画
transform（translate/scale/rotate）和opacity - 元素已启用硬件加速（加
will-change: transform或transform: translateZ(0)） - 没同时监听
scroll或mousemove并触发重排（layout）
一旦混入 left / top / width / height 等触发布局的属性，浏览器就得每帧计算几何，CPU 使用率立刻跳升，尤其在低端 Android 设备上明显卡顿。
Lottie 渲染引擎选错，CPU 负担翻倍
同一份 Lottie JSON 文件，在不同渲染器下 CPU 表现差异极大：
-
renderer: 'svg'：DOM 节点多时内存涨得快，但 CPU 相对温和；适合静态图标类动画 -
renderer: 'canvas'：像素级绘制，CPU 压力大但内存可控；适合中等复杂度、需频繁重绘的场景 -
renderer: 'html'：依赖 CSS 3D 变换，低端设备兼容差，且transform-style: preserve-3d在某些 Android WebView 下会强制回退到软件渲染
查法：打开 Chrome DevTools → Performance → 录制动画过程 → 看 Rendering 和 Scripting 时间占比。若 Scripting > 60%，优先换 SVG 渲染器；若 Rendering > 50%，说明绘制管线压爆，得降分辨率或简化图层。
怎么快速定位是谁在吃 CPU
别猜，用浏览器原生工具抓：
- Chrome：打开
chrome://performance→ 点 Record → 播放动画 → 停止后看火焰图，聚焦Animation Frame Fired下的 JS 调用栈 - Firefox：
about:performance→ 找到你的标签页 → 点「详细信息」看 JS 堆使用和事件循环延迟 - 命令行辅助：
chrome --enable-precise-memory-info --js-flags="--trace-gc"启动，观察 GC 频率是否异常高
特别注意：移动端真机调试容易被忽略的一点——很多低端 Android 机器的 GPU 驱动不支持 Canvas 的离屏渲染（OffscreenCanvas），所有绘制都在主线程完成，这时候哪怕逻辑再轻，CPU 也扛不住。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
