动画一开cpu就飙高，大概率是触发了layout重排；修改width/height/left/top等属性会强制每帧执行layout和paint，而transform和opacity仅走gpu合成，可显著降低cpu占用。
动画一开CPU就飙高，大概率是触发了 Layout 重排
浏览器每帧动画若涉及 width、height、left、top、margin、padding 等属性变更，就会强制执行 Layout（重排），接着连带 Paint（重绘），最终拖垮帧率。这类操作全在主线程完成，CPU 占用自然飙升——尤其在 Safari 或旧版 Firefox 中更明显。
验证方法很简单：打开 Chrome DevTools → Performance 面板 → 录制一段动画 → 查看火焰图中是否密集出现 Layout 和 Paint 任务。如果 Layout 占比高，基本可以锁定问题根源。
哪些 CSS 属性动了会立刻触发重排
不是所有动画属性都“安全”。以下属性只要在动画中被修改，浏览器就必须重新计算整个布局树：
-
width/height/min-height/max-width -
margin/padding/border-width -
top/bottom/left/right（配合position: relative/absolute） -
display/float/clear -
font-size/line-height（影响内联盒尺寸）
这些属性哪怕只改 1px，也会让浏览器放弃优化路径，回到最重的渲染流水线。而 transform 和 opacity 则完全绕过 Layout 和 Paint，只走 Composite 阶段，GPU 合成即可。
如何快速把高开销动画改成低开销写法
不用重写逻辑，只需替换关键属性和补一层合成提示：
- 把
left: 100px改成transform: translateX(100px) - 把
top: 50px改成transform: translateY(50px) - 把
width: 200px改成transform: scaleX(2)（需配合transform-origin控制缩放锚点） - 给动画元素加
will-change: transform或transform: translateZ(0)，显式提示浏览器升层 - 避免在同一个元素上同时用
box-shadow+gradient+ 动画——它们本身 Paint 开销就大，叠加后极易卡顿
注意：translate3d(0, 0, 0) 虽然能强制升层，但滥用会导致内存占用上升，图层过多反而降低性能。优先用 will-change，且仅在动画开始前 1–2 帧设置，动画结束立即移除。
为什么 Safari 和 Firefox 表现差异大
Chrome 对 transform/opacity 的合成优化最激进；Safari 对 will-change 支持不稳定，有时忽略或延迟升层；Firefox 在某些版本中对 transform: scale() 的插值计算未 GPU 加速，仍走 CPU 路径。
实操建议：
- 用
transform: translateX()替代left，三端兼容性最好 - 避免
transform: rotateZ()配合大尺寸元素——Firefox 可能 fallback 到软件渲染 - 动画元素不要设
overflow: hidden+transform组合，Safari 会禁用合成层优化
真正容易被忽略的点是：动画元素父容器的 transform-style: preserve-3d 或 perspective 会污染子元素图层策略，导致本该独立的动画层被合并——这种隐式耦合很难从 DevTools 直观发现。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
