HTML动画本身不提升CPU占用，真正决定CPU负载的是实现方式、触发频率、DOM操作强度及是否阻塞主线程；requestAnimationFrame比setTimeout更可控，因其对齐刷新率且后台自动暂停，而setTimeout会持续轮询耗电；transform和opacity因硬件加速几乎不占CPU，但top/left等属性会强制重排导致高负载；Canvas卡顿多因JS逻辑瓶颈或绘制失控，而非CPU性能不足；动画烫机问题90%源于代码层，应通过Performance面板定位Scripting瓶颈。
HTML动画本身不会“提升”CPU占用——它只是触发条件；真正决定CPU是否狂转的，是动画实现方式、触发频率、DOM操作强度和是否意外阻塞主线程。
用 requestAnimationFrame 写动画比 setTimeout 更省 CPU 吗
不是“更省”，而是“更可控”。requestAnimationFrame 会自动对齐屏幕刷新率（通常 60fps），并在标签页不可见时暂停调用；而 setTimeout(fn, 16) 是硬性轮询，即使页面被最小化或切到后台，它仍持续执行，白白消耗 CPU。
- Chrome 中打开多个含
setTimeout动画的标签页，每个都会维持独立计时器，Node.js 或渲染进程可能因事件队列积压而升温 -
requestAnimationFrame在页面非激活状态（如切换 Tab）下自动暂停，等同于天然节流 - 但若你在
requestAnimationFrame回调里做了大量 DOM 读写（比如反复查offsetHeight或连续innerHTML = ...），照样引发重排风暴，CPU 占用飙升
transform 和 opacity 动画为什么几乎不占 CPU
因为现代浏览器对这两个 CSS 属性做了硬件加速路径：只要不触发 layout 或 paint，GPU 就能直接合成图层，主线程几乎不参与计算。
- 触发硬件加速的前提是该元素已提升为独立图层（常见手段：
transform: translateZ(0)或will-change: transform） - 但滥用
will-change会导致图层过多，内存占用上升，反而拖慢 GC，间接拉高 CPU -
top/left/width/height等属性动画必须走 layout → paint → composite 流程，每次变化都强制重排，CPU 持续满负荷 - 实测中，一个 200×200px 元素用
left动画滚动时，Chrome Performance 面板中Layout时间占比常超 40%；换成transform: translateX()后，Layout接近 0，Composite Layers时间主导，CPU 曲线平缓
Canvas 动画卡顿，是不是 CPU 不够
不一定。Canvas 卡顿更大概率来自 JS 逻辑瓶颈或绘制频次失控，而非 CPU 物理性能不足。
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
立即学习“前端免费学习笔记（深入）”；
- 在低端 Android 设备上，
requestAnimationFrame回调里每帧调用 50+ 次ctx.fillRect()并做坐标计算，很容易跌破 30fps——这不是 CPU 不行，是 JS 执行时间挤占了渲染余量 - 未使用
createImageBitmap预解码图片、或每帧重复drawImage大图，会频繁触发纹理上传，GPU 等待阻塞主线程 - LayaAir 或 PixiJS 等引擎中，DrawCall 超过 100 次/帧，即使 CPU 闲着，GPU 提交压力也会让动画掉帧
- 用
performance.now()包裹一帧逻辑，确认耗时是否稳定在 16ms 内；超过就说明 JS 执行拖后腿，和 CPU 主频关系不大
动画过程中风扇狂转，先查这三件事
别急着换电脑或降频，90% 的“动画烫机”问题出在可干预的代码层。
- 打开 Chrome DevTools →
Performance面板，录制 5 秒动画，重点看Scripting时间占比 —— 若 > 60%，说明 JS 执行是瓶颈，不是动画本身的问题 - 检查是否在动画循环中无意调用了
console.log输出 DOM 节点或大对象，DevTools 开着时这会深度遍历并渲染整个子树 - 确认没在
scroll或resize事件里直接跑动画逻辑，必须加节流（requestAnimationFrame+ 标志位）或防抖，否则滚动一秒钟触发上百次重绘
真正难排查的是那些“看起来很轻”的操作：比如每帧读一次 getBoundingClientRect()，或在 Canvas 动画里用 for...in 遍历动态对象——它们单次开销小，但高频叠加后，CPU 缓存失效、GC 压力、JS 引擎优化失败，全来了。
