transform 和 opacity 能跳过回流，因其变更由合成器处理，仅重绘纹理而不触发布局计算；现代浏览器已自动为 transform 动画创建合成层，无需手动加 translateZ(0)。
transform 和 opacity 是目前最可靠、兼容性最好、副作用最小的减少重绘（甚至避免回流）的 CSS 动画手段。用它们替代 left、top、width、height、margin 等会触发布局计算的属性，能直接绕过 Layout 阶段，把渲染压力交给 GPU。
为什么 transform 和 opacity 能跳过回流？
浏览器在解析样式时，如果发现只修改了 transform 或 opacity，就会把该元素提升为独立的合成层（compositing layer），后续变化仅需重绘该图层的纹理，不重新计算位置或尺寸。这本质上是“不动布局，只动像素”。
-
transform: translateX(100px)不改变文档流，也不影响其他元素布局；而left: 100px会强制触发回流，因为它依赖于父容器的定位上下文 -
opacity: 0.5只影响最终混合阶段，不改变几何信息；但visibility: hidden虽然也隐藏，却仍保留在渲染树中，且某些场景下会间接影响布局（比如配合display: inline的兄弟元素） - 注意：
will-change: transform可提前提示浏览器创建合成层，但滥用会导致内存占用上升，建议只在动画开始前 1–2 帧设置，动画结束后移除
translateZ(0) 和 translate3d(0,0,0) 到底要不要加？
它们本质是“骗”浏览器创建新图层，属于历史兼容方案。现代 Chrome/Firefox/Safari 在检测到 transform 动画时已自动启用合成层，**不需要手动加 translateZ(0)**。
- 加了可能反而引发不必要的图层分裂，尤其在大量元素上使用时，导致内存暴涨、滚动卡顿
- 只有在旧版 Safari（transform: translate3d(0, 0, 0)
- 更稳妥的做法是：用
transform: translateX(0)触发硬件加速，再叠加真实位移，既简洁又无副作用
CSS 动画 vs JavaScript 动画：什么时候必须用 JS？
CSS 动画（@keyframes + animation）天然走合成管线，只要属性限定在 transform/opacity，就几乎不会触发回流。但它的局限也很明确：
- 无法响应用户交互做动态插值（比如拖拽中实时更新
transform值）——这时必须用requestAnimationFrame+element.style.transform - 无法精确控制暂停/倒放/跳帧 ——
animation-play-state支持有限，复杂状态机建议用 GSAP 或原生 Web Animations API - 级联动画（多个元素按顺序触发）用 CSS 写起来冗长易错，JS 控制更清晰
容易被忽略的“隐式回流”陷阱
即使你全程只用 transform，以下操作仍可能意外触发回流：
立即学习“前端免费学习笔记（深入）”；
- 读取
offsetTop、getBoundingClientRect()、getComputedStyle().width等布局信息后，紧接着修改transform—— 浏览器会强制刷新队列，把前面的读操作变成“同步回流” - 在
transition过程中，反复切换 class 并修改transform，若 class 中混入了display: none或height，整个过渡链就失效 - 父容器用了
flex或grid，子元素transform后，若父容器尺寸被 JS 动态修改（比如 resize 监听器里改style.width），仍会连带回流
transform，而是确保整条渲染链路里没有“漏网之鱼”——一个 clientWidth 调用、一次未合并的 class 切换、一段混用的 top 动画，都可能让 GPU 加速失效。优化得越深，越要盯着 DevTools 的 Rendering 面板看“Layout”是否真的消失了。 
