HTML动画高CPU占用主因是强制同步布局；应只改transform/opacity、走合成层，避left/top、同步读取及filter/box-shadow等耗能操作。
HTML 动画本身不能改善 CPU 占用，反而常是高 CPU 占用的直接诱因；真正能压低 CPU 使用率的，是避开强制同步布局、只动 transform 和 opacity、并让动画走合成层。
为什么改 left/top 会让 CPU 狂飙
浏览器对 left、top、width 这类属性的修改，每帧都会触发 layout → paint → composite 全流程。主线程必须重新计算所有依赖关系、重排 DOM、重绘像素——这不是“多算一点”，而是每 16ms 就来一次硬性重排。即使加了 will-change: transform，也救不了 top 的 layout 开销。
-
transform: translateX(10px)只改图层位置，GPU 合成器直接处理，主线程几乎不参与 -
left: 10px必须查父容器尺寸、浮动元素、margin 折叠……一帧内反复读写就引发“布局抖动” - Chrome DevTools → Rendering → 勾选 “Layout Shift Regions”，动起来时看到大片紫色，基本就是
left/top在作祟
在 requestAnimationFrame 里读 offsetTop 是最隐蔽的坑
很多人以为用了 requestAnimationFrame 就安全了，结果在回调里随手写一句 el.offsetTop 或 el.getBoundingClientRect()，CPU 占用立刻翻倍。这不是函数的问题，而是读取动作强制浏览器把上一帧没完成的 layout 补上，打断渲染流水线。
- ✅ 正确做法：事件响应时缓存值（如点击后立刻读
getBoundingClientRect()），动画帧里只写样式 - ❌ 错误模式：
function animate() { const y = el.offsetTop; el.style.top = y + 1 + 'px'; requestAnimationFrame(animate); } - 替代方案：用
ResizeObserver或IntersectionObserver异步监听变化，完全避开同步读取
filter 和 box-shadow 看似不触发布局，实则暗耗 CPU
filter: blur(2px) 或 box-shadow: 0 4px 8px rgba(0,0,0,0.2) 不会触发 reflow，但会迫使浏览器放弃硬件加速，切回 CPU 软件渲染。尤其在滚动中叠加使用，或作用于多个元素时，合成器负担陡增，CPU 占用曲线会突然拉高。
立即学习“前端免费学习笔记（深入）”；
- blur 值越大、阴影越深、元素越多，CPU 消耗越非线性增长
- iOS Safari 对
filter更敏感，容易导致图层降级，帧率直接掉到 20–30fps - 验证方式：DevTools → Rendering → 勾选 “Paint flashing”，频繁大面积绿色闪烁即为重绘风暴
最容易被忽略的是“动多少”比“怎么动”更关键：10 个元素用 transform 动，和 1000 个一起动，CPU 压力差一个数量级。别急着调 will-change，先做元素裁剪、用 IntersectionObserver 控制可视区动画启停——白跑的动画，再高效也是浪费。
