会强制触发重排的CSS动画属性包括width、height、margin、padding、border、top、left、right、bottom、font-size、line-height、display；因其修改盒模型或布局位置，每帧都触发Layout计算，开销远高于重绘或合成。
因为浏览器必须重新计算整个布局树中所有受影响元素的几何位置和尺寸，这不是可选优化，而是渲染引擎的强制流程。
哪些CSS属性动画会强制触发重排
只要在 @keyframes 或 transition 中修改以下任一属性，每帧都会触发一次 Layout：
-
width/height：直接改变元素占用空间，兄弟元素、父容器高度、换行位置都可能连锁变动 -
margin/padding/border：盒模型参数变化，影响外边距塌陷、内边距撑开、边框占位等布局行为 -
top/left/right/bottom（配合position: relative或absolute）：偏移量变化需重新定位该元素及其后代在文档流中的坐标 -
font-size/line-height：文本尺寸变更可能导致行高重算、换行点移动、父容器高度跳变 -
display（如display: none↔block）：元素进出文档流，整棵子树被剔除或重建
为什么重排开销远高于重绘或合成
重排不是“重画一下”，而是从根节点开始，对渲染树中所有相关节点执行完整几何计算：
- 涉及 DOM 深度越深，需要重新 layout 的节点越多；
body前插入一个元素，可能触发全页面重排 - 每次读取
offsetWidth、getBoundingClientRect()等布局 API，都会强制同步触发一次重排（即使没改样式） - 动画每秒 60 帧，意味着每 16ms 就要跑一遍 layout → paint → composite 流程；一旦 layout 占用超 8ms，帧率必然跌破 60fps
- Chrome DevTools Performance 面板中若看到密集的
Layout柱状图，基本可断定是这些属性在拖慢主线程
用 transform 替代 width/height 的实操要点
transform: scale() 看似能“模拟”宽高变化，但实际行为差异很大，不能无脑替换：
立即学习“前端免费学习笔记（深入）”；
- 缩放原点默认是中心，
scale(2)会让元素视觉放大但位置偏移；加transform-origin: top left可对齐左上角基准 - 缩放后元素的 layout size（即文档流中占位）仍是原始尺寸，兄弟元素不会跟随“撑开”，父容器也不会自适应增高
- 子元素文字、图标、边框也会被同比例放大；如只需放大容器不放大内容，得对子元素反向缩放：
transform: scale(0.5) - 响应式场景下，若元素宽高由
width: 100%或flex决定，“原始尺寸”本身就不稳定，scale(1.2)在不同屏幕下视觉效果不一致 - 起始帧必须显式声明
transform: scale(1)，否则动画可能因未初始化而跳过过渡
真正难处理的是那些必须改变 layout size 的场景——比如卡片展开后要撑开父容器、列表项逐个 height 动画展开。这时 transform 无法替代，得靠 max-height + overflow: hidden 或 JS 测量 + height: auto 过渡，代价是仍会触发重排，只能控制频率和范围。
