CSS动画本身不会必然导致重排，但修改width、height、top/left/right/bottom、margin/padding/border、display等布局属性会强制重排；而transform和opacity仅触发合成，不重排不重绘。
直接说结论：CSS动画本身不会必然导致重排，但只要动画修改了会触发布局计算的属性（比如 width、left、margin），浏览器就必须执行重排——这是性能卡顿的根源。
哪些CSS动画属性会触发重排？
重排发生在浏览器需要重新计算元素几何信息时。以下动画中常见的属性，只要参与 transition 或 @keyframes，就会强制重排：
-
width/height：改变尺寸，影响后续元素流式布局 -
top/left/right/bottom（配合position: relative/absolute）：脱离文档流但仍需参与布局坐标计算 -
margin/padding/border：直接影响盒模型尺寸和位置 -
display切换（如block↔none）：整个元素进出渲染树
注意：opacity 看似“视觉变化”，但它只触发合成（Composite），不重排也不重绘；而 visibility: hidden 虽隐藏元素，但保留占位，不重排，只重绘。
为什么用 transform 和 opacity 就不重排？
因为浏览器对这两个属性做了特殊优化：它们不参与布局计算，只影响图层的最终合成阶段。元素会被提升为独立图层（Layer），由 GPU 直接处理位移、缩放、透明度变化，主线程完全不用介入 Layout 或 Paint。
立即学习“前端免费学习笔记（深入）”；
实操建议：
- 把
left: 20px改成transform: translateX(20px) - 把
width: 200px改成transform: scaleX(1.5)（需配合transform-origin控制缩放中心） - 动画中需要“显示/隐藏”时，优先用
opacity: 0+pointer-events: none，而非display: none
⚠️ 注意：transform: translateZ(0) 或 translate3d(0,0,0) 是手动触发图层提升的 hack，但现代浏览器已能自动识别 transform 动画并升层，无需额外加。
will-change 和硬件加速要不要加？
will-change 是个双刃剑：它提前告诉浏览器“这个元素接下来要变 transform 和 opacity”，让浏览器预先分配图层资源。但滥用会导致内存浪费、图层爆炸，尤其在大量元素上设 will-change: transform 反而拖慢首屏。
建议这样用：
- 只在真正需要高频动画的元素上设置，且仅在动画开始前动态添加：
element.style.willChange = 'transform, opacity' - 动画结束后立刻清除：
element.style.willChange = 'auto' - 避免在 CSS 中全局写死
will-change: transform—— DevTools 的 Layers 面板里能看到冗余图层就是信号
至于 backface-visibility: hidden 或 perspective: 1000px，它们本质也是图层提升手段，效果类似 translateZ(0)，但语义更清晰；不过只要用了标准 transform 动画，通常不需要再叠这些。
最容易被忽略的一点：动画是否触发重排，和你用 transition 还是 @keyframes 完全无关，只取决于你改的是哪个属性。哪怕写得再 fancy 的 animation，只要关键帧里写了 left，照样掉帧。
