会强制触发重排的CSS动画属性包括：width、height、top、left、right、bottom、margin、padding、border、font-size、line-height、display；opacity和transform除外，但混用任一触发属性即降级为重排。
CSS动画本身不会直接导致重排，但只要动画中修改了会触发布局计算的属性（比如 width、left、top、margin），浏览器就必须执行重排——这不是“可能”，而是渲染引擎的硬性流程。
哪些CSS动画属性会强制触发重排？
只要在 @keyframes 或 transition 中使用以下任一属性，就等于主动调用重排：
-
width/height：尺寸变化必然影响周围元素流式布局 -
top/left/right/bottom：定位偏移需重新计算文档流位置 -
margin/padding/border：盒模型参数变更，布局树必须重算 -
font-size/line-height：文本尺寸变化可能引起行高、换行、父容器高度连锁反应 -
display（如display: none↔block）：元素进出布局树，整棵子树重排
注意：opacity 和 transform 是例外——它们不参与 layout 阶段，只走合成层（compositing），所以不会重排。但前提是：没混入其他触发属性。哪怕关键帧里只写了一次 left: 0，整个动画就降级为 CPU 渲染，重排照常发生。
Chrome DevTools 里怎么确认是不是真发生了重排？
别信直觉，看 Layers 面板和 Performance 录制才是唯一可靠方式：
立即学习“前端免费学习笔记（深入）”；
- 打开
DevTools → More Tools → Layers：如果动画元素没出现在独立图层列表里，说明它没被提升，大概率在走重排路径 - 录制一段动画操作（
Performance面板 → 点录制 → 播放动画 → 停止）：展开底部的Bottom-Up视图，搜索Layout，耗时 >1ms 就值得警惕；若 Layout 占比超过 15%，基本可判定是重排拖慢了帧率 - 别只盯着
Repaint：重绘开销小，重排才是性能杀手。很多卡顿问题查Paint耗时反而绕远路
一个小技巧：getComputedStyle(el).width 这类读取操作，如果穿插在动画循环中（比如 requestAnimationFrame 里先读再改），也会强制同步触发重排——因为浏览器必须返回当前真实布局值。
为什么 class 切换比 style 动态赋值更安全？
本质是浏览器能否批量合并样式计算：
- 写
el.style.left = '10px'：每次赋值都可能单独触发一次重排，10 次就是 10 次 layout - 用
el.classList.add('slide-in')：CSS 规则已预编译，浏览器能识别出这是“一批样式变更”，通常只合并为 1 次重排（甚至 0 次，如果只是transform类） - 额外好处：CSS 文件可被缓存、压缩、复用；JS 拼接的
style.cssText或逐个设style.xxx完全绕过这些优化
但要注意：如果那个 slide-in class 里写了 left: 10px，照样重排——class 只是载体，关键还是看里面用了什么属性。
动画开始前手动升层，will-change 真的有用吗？
有用，但代价明确，不是开关，是内存预分配指令：
-
will-change: transform会让浏览器提前创建纹理、分配显存、把元素升到独立合成层——这能避免动画启动瞬间的卡顿（即“首帧掉帧”） - 但它不解决根本问题：如果动画本身还在改
width，升层也救不了，重排照旧 - 滥用后果严重：每个加了
will-change的元素都会吃 GPU 内存；全局加或长期挂着，等于主动制造内存泄漏 - 正确姿势：动画开始前 1–2 帧动态加，结束立即设回
auto；用transform: translateZ(0)或translate3d(0, 0, 0)替代更轻量
真正容易被忽略的点是：父容器的 filter、clip-path 或非 transform: none 的变换，会压制所有子元素的 GPU 加速——即使你给子元素加了 transform，它也合并在父层绘制，失去独立图层优势。
