真正安全的动画属性只有transform和opacity，它们走合成层不触发重排；需合并transform值、用translatez(0)提升图层、避免每帧读布局、配合contain: paint缩小重绘范围，并用layers面板验证图层提升成功。
哪些 CSS 属性改起来会立刻重排，动画里必须避开
直接改 left、top、width、height、margin、padding 会在每一帧都触发重排，尤其在 requestAnimationFrame 循环里——浏览器不得不每帧都重新计算布局树。这不是“卡一点”，而是帧率掉到 20fps 以下的常见原因。
真正安全的动画属性只有两个： transform（含 translate、scale、rotate）和 opacity。它们走的是合成层（compositing layer），不碰 layout，只触发 GPU 合成。
- 别用
transform: translateX(10px)+transform: translateY(5px)分两次设——合并成transform: translate(10px, 5px)，否则第二次会覆盖第一次且可能触发额外样式计算 -
transform: scale(1)和transform: scale(1.0001)效果一样，但后者更可靠地触发硬件加速（尤其在旧版 Safari） - 避免对未设置宽高的
display: inline元素直接加transform，它可能因 baseline 计算不稳定而意外重绘
怎么让动画元素真正脱离文档流，不拖慢兄弟节点
光加 transform 不够——元素还在文档流里，父容器仍要为它预留空间、参与行高计算。真正隔离靠的是图层提升（layer promotion）。
最稳妥的方式是用 transform: translateZ(0) 或 will-change: transform，把元素变成独立合成层。但注意：will-change 是“预告”，不是“开关”，加太多反而增加内存开销和图层管理负担。
- 移动端优先用
transform: translateZ(0)，Safari 对will-change支持弱且易误触发 - 不要给静态图标、文字块等非动画元素加提升声明，它们不会动，却占着 GPU 内存
- 多个相邻动画元素，建议包裹进同一个
<div>，只对该容器提升图层，而不是每个子项都单独提升 <li>提升后元素行为类似 <code>position: absolute，若布局错位，检查是否依赖了原本的文档流位置 - 如果必须读取位置做逻辑判断（比如碰撞检测），先缓存一次结果，在后续几帧内复用，而非每帧都读
- 用
element.getClientRects()替代getBoundingClientRect()可能略快，但本质没区别，关键还是避免每帧读 - Chrome DevTools 的 Rendering 面板打开 “Layout Shift Regions” 和 “FPS Meter”，能直观看到哪一行 JS 触发了 forced layout
- 生产环境可降级写法：
contain: paint单独一行，不跟layout或style混用，避免部分浏览器解析失败导致整条规则失效 - 别对 body 或大范围 layout 容器加
contain，它会切断子元素与外部样式的继承链（比如根字号变化不生效） - 配合
transform使用效果最佳：先用contain: paint锁定绘制边界，再用transform驱动动画，双重隔离
为什么 getBoundingClientRect() 在动画循环里是性能杀手
在 requestAnimationFrame 回调里调用 getBoundingClientRect() 或 offsetTop，等于告诉浏览器：“我现在就要最新 layout 数据”，它只能立刻 flush 队列、强制同步重排，打断整个渲染流水线。动画越快，这个打断越频繁。
正确做法是：把所有读操作集中到一帧开头，所有写操作（如设 transform）集中到结尾——即“读-写分离”。
contain: paint 能省多少重绘，什么时候该用
contain: paint 告诉浏览器：“这个容器内部的变化，绝不会影响外部绘制”，于是浏览器在重绘时直接跳过检查它的边界外区域。它比单纯提升图层更进一步——不仅跳过重排，还缩小重绘范围。
适合用在：轮播图容器、弹窗浮层、动态列表区块。但要注意兼容性：IE 完全不支持，iOS Safari 15.4+ 才稳定支持。
transform”，而是“加了之后有没有检查它是否真成了独立图层”。Chrome DevTools 的 Layers 面板里点开那个小眼睛图标，才能确认提升成功——否则写的全是白费。
