css动画比js动画更省cpu，因其通过合成线程处理transform/opacity，避免主线程重排重绘；requestanimationframe优于setinterval，因它同步屏幕刷新率且标签页隐藏时自动暂停。
HTML 动画本身不直接“依赖 CPU 占用”，但动画的实现方式决定它是否吃 CPU——关键在你是用 CSS 还是 JavaScript 控制，以及是否触发重排/重绘。
CSS 动画比 JS 动画更省 CPU 吗
是的，多数情况下更省。浏览器对 transform 和 opacity 的 CSS 动画会走合成层（compositor thread），不经过主线程 Layout/Paint，几乎不增加 JS 执行负担。
- ✅ 推荐写法：
transition: transform 0.3s ease;或@keyframes slide { to { transform: translateX(100px); } } - ❌ 避免写法：
transition: left 0.3s;或top/width等触发布局的属性——每次变化都强制重排，CPU 持续拉高 - ⚠️ 注意：加了
will-change: transform;并不能自动优化，反而可能提前创建图层、多占内存；只在必要时（如长时动画）谨慎使用
requestAnimationFrame 为什么比 setInterval 更稳
requestAnimationFrame 让动画帧率与屏幕刷新率同步（通常是 60fps），且在标签页不可见时自动暂停；而 setInterval 不管页面是否激活，照常执行，白耗 CPU。
- ✅ 正确用法：
function animate() { /* 更新逻辑 */ requestAnimationFrame(animate); } - ❌ 错误习惯：用
setInterval(() => { elem.style.left = ++x + 'px'; }, 16)—— 无法节流、易丢帧、页面切后台还在跑 - ? 补充：如果动画逻辑复杂（比如粒子计算），建议把耗时部分挪进
Web Worker，避免阻塞requestAnimationFrame主线程调度
Canvas 动画 CPU 占用高的常见原因
Canvas 本身不“智能”，每帧都是全量重绘，CPU 压力来自你写的逻辑，不是 Canvas 标签本身。
- ❌ 每帧清空整个 canvas 再重画（
ctx.clearRect(0,0,w,h)）+ 大量对象绘制 → 显存带宽和 CPU 解码压力双高 - ✅ 优化方向：只重绘变化区域（
ctx.clearRect(x,y,w,h)）、复用ImageBitmap、用OffscreenCanvas在 Worker 中预渲染 - ⚠️ 特别注意 Android 设备：部分低端 GPU 不支持 Canvas 合成加速，所有绘制退化为 CPU 软渲染，
ctx.drawImage频繁调用极易卡顿
怎么快速判断动画是不是 CPU 瓶颈
打开 Chrome DevTools → Performance 标签 → 点录制 → 播放动画 → 停止后看火焰图顶部是否持续红/黄（JS 执行或 Recalculate Style 占满主线程）。
- ? 如果
Layout或Recalculate Style高频出现 → 检查是否用了offsetTop、getComputedStyle等强制同步布局的 API - ? 如果
Scripting占比高 → 定位到具体函数，看是不是每帧都在做数组遍历、JSON 解析、DOM 查询等非必要操作 - ? 如果
Rendering和Painting高但Scripting低 → 说明是绘制量过大，考虑降分辨率、合批绘制、或启用contain: paint;隔离渲染范围
真正卡住你的，从来不是“HTML 动画”这个概念，而是你没意识到 left 和 transform 的调度线程完全不同，也没留意 requestAnimationFrame 在后台标签页里早就停了——这些细节，才是 CPU 风扇狂转或静音运行的分水岭。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
