触发布局（重排）的css属性包括width、height、top、left、margin、padding、border；它们改变元素几何尺寸或位置关系，迫使浏览器重新计算布局树，开销极大。
哪些CSS属性触发布局（重排）？
改width、height、top、left、margin、padding、border这些会直接改变元素几何尺寸或位置关系的属性，浏览器必须重新计算整个布局树——这就是重排。它开销极大，尤其在动画中频繁触发时，帧率立刻掉到30fps以下。
常见错误现象：transform: translateX(10px)和left: 10px看起来效果一样，但后者强制重排，前者只走合成层；用opacity做淡入比用visibility或display切换更安全，因为后两者会触发重排+重绘。
- 能用
transform和opacity实现的位移/缩放/透明度变化，就别碰top/left/width -
will-change: transform不是万能药，只对即将动画的元素提前声明，且别滥用（比如全页面加） - 避免在
scroll事件里动态修改top或margin来实现视差，改用transform: translateY()+passive: true
怎么判断一个元素是否进了GPU合成层？
Chrome DevTools 的「Layers」面板（需在Rendering面板中勾选）能直观看到哪些元素被提升为独立图层。但更实用的方法是看是否满足以下任一条件：transform非none、opacity小于1、filter有值、will-change声明了可动画属性、position: fixed且有z-index。
注意：合成层不是越多越好。每个图层都要占用GPU内存，过多会导致内存暴涨甚至页面崩溃，尤其在移动端。
立即学习“前端免费学习笔记（深入）”；
- 用
transform: translateZ(0)强行提层是过时做法，现代浏览器已优化，优先用语义明确的transform: translateX(0) -
backface-visibility: hidden有时能辅助触发合成，但仅当配合transform: rotateY(180deg)类3D变换时才有效，纯2D动画不必加 - 检查
chrome://gpu确认硬件加速已启用，否则合成层可能退化为CPU绘制
为什么requestAnimationFrame比setTimeout更适合驱动CSS动画？
因为requestAnimationFrame（简称raf）由浏览器统一调度，保证每次回调都在下一帧开始前执行，与屏幕刷新率（通常是60Hz）严格对齐。而setTimeout(fn, 16)只是“约等于”16ms，实际延迟受JS主线程阻塞、任务队列积压影响，极易丢帧。
使用场景：当你需要用JS控制动画节奏（比如滚动联动、手势拖拽），或者需要在动画关键帧中读取getBoundingClientRect()等触发重排的API时，raf是唯一靠谱选择。
- 不要在
raf回调里写大量计算或DOM操作，否则会挤占渲染时间，导致卡顿 - 用
raf读取位置、再用transform写回，形成“读-写”分离，避免强制同步布局 - 动画结束记得调用
cancelAnimationFrame，尤其在组件卸载或条件中断时，否则容易内存泄漏
移动端iOS Safari上动画卡顿的典型原因
iOS Safari对合成层管理更保守，很多在Chrome里自动提层的动画，在Safari里仍走主渲染线程。最常踩的坑是：用transform: scale()但没加-webkit-transform前缀（虽然现代版本已不强制，但部分iOS 14–15仍需），或用了filter: blur()却没配transform: translateZ(0)来兜底提层。
另一个隐形杀手是overflow: scroll容器内的子元素动画——iOS会禁用该区域的合成优化，哪怕子元素本身满足提层条件。
- 给动画元素显式加
transform: translate3d(0, 0, 0)比translateZ(0)兼容性更好 - 避免在
body或html上设置overflow-x: hidden，这会让整个页面失去合成优化机会 - 用
prefers-reduced-motion: reduce媒体查询降级动画，不是锦上添花，而是iOS用户真实需求
重排重绘的代价藏在每一行样式里，而合成层的边界往往由一个没写的transform或一个多余的margin决定。真正难的不是知道原理，是在业务代码里一眼识别出那个“看似无害”的属性正在拖垮帧率。
