html动画是否依赖cpu取决于技术选型：requestanimationframe和css transform/opacity走gpu加速，而top/left等触发重排的js动画则持续占用cpu。
HTML动画是否依赖CPU，取决于你用的是哪类动画技术——requestAnimationFrame 和 CSS transform/opacity 动画基本走 GPU 加速，不明显吃 CPU；而用 top/left、width/height 或频繁操作 innerHTML 触发重排（reflow）的 JS 动画，会持续拉高 CPU 占用，尤其在低端设备或复杂页面中容易卡顿。
为什么 top 和 left 动画特别耗 CPU
每次修改 top 或 left 这类布局属性，浏览器必须重新计算整个渲染树（reflow），再重绘（repaint），这个过程完全在主线程执行，无法卸载到 GPU。叠加 setInterval 高频轮询，CPU 使用率很容易飙到 30%~70%。
- 避免直接改
style.top/style.left，改用transform: translate(x, y) - 确保元素有独立合成层：加
will-change: transform或transform: translateZ(0)（后者兼容性更好） - 不要在动画中读取
offsetTop、getBoundingClientRect()等触发同步布局计算的 API
requestAnimationFrame 不等于低 CPU，关键看它里面干了啥
requestAnimationFrame 只是把回调对齐屏幕刷新节奏，本身不省 CPU。如果回调里做了 DOM 查询、样式读写、大数组遍历或未节流的事件响应，照样卡。
- 动画帧内只做「纯视觉更新」：如
element.style.transform = `translate(${x}px, ${y}px)` - 把数据计算提前到动画开始前，或用
Web Worker拆分逻辑（例如路径预计算） - 用
performance.now()监控单帧耗时，超过 12ms（83fps 下）就要优化
Chrome DevTools 快速定位动画 CPU 瓶颈
打开 Performance 面板 → 录制一段动画 → 查看 Main 线程火焰图，重点关注三类高亮块：
-
Layout（橙色）：说明有强制同步布局，立刻检查是否有样式读写混用 -
Recalculate Style（紫色）：CSS 计算开销大，考虑减少嵌套选择器或动态 class 切换频率 - 长任务（红色条）：JS 执行太久，确认是否在
raf回调里做了非渲染工作
右键对应条目 → View call stack，能直接看到是哪行 JS 触发的瓶颈。
真正压低 CPU 的核心不是“用不用动画”，而是“让浏览器少做重排重绘，多交由 GPU 处理”。很多团队花时间调 transition-timing-function，却忽略一个 margin-top 动画正在后台偷偷吃掉 40% CPU——这种细节，往往只在真机 + 低电量模式下才暴露得最清楚。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
