transform 触发合成层位移，不触发重排和重绘；而 top/left 每次变化都强制重排，单帧 layout 耗时 1–3ms，60fps 下累计 cpu 开销达 60–180ms/秒，导致掉帧。
直接说结论：transform 触发的是合成层（compositor）位移，不走重排（reflow）和重绘（paint）；而 top、left 等位置属性每次变化都强制浏览器重新计算布局，主线程卡顿是常态。
为什么 top/left 动画会掉帧
浏览器渲染流水线里，top 和 left 是 layout 属性。哪怕元素已设 position: absolute，修改它们仍会触发轻量级 layout 计算——Chrome 实测单帧 layout 耗时 1–3ms，动画每秒更新 60 次，累积就是 60–180ms/秒的 CPU 开销。
DevTools Performance 面板中能看到密集的黄色 “Layout” 块；滚动中叠加这类动画，帧率很容易跌破 45fps。
-
top: 100px→ 浏览器必须校验父容器是否被撑开、兄弟元素是否位移、margin/padding 是否影响边界 - 动画期间每帧都要走 Layout → Paint → Composite 全流程
- 移动端尤其明显：部分 Android WebView 对 layout 变更响应更慢，卡顿感知更强
为什么 transform: translate() 能绕过主线程
transform: translate() 不改元素在文档流中的位置、尺寸或盒模型，只告诉 compositor：“把这个图层往 X/Y 方向挪 N 像素”。GPU 直接操作像素块，主线程几乎不参与。
- 浏览器自动为其创建独立合成层（compositing layer），只要没被
filter或opacity中断 - 实测同个 3 秒动画：
top方案累计 layout 耗时约 80ms，translate仅约 8ms - Performance 面板里几乎只剩 “Composite Layers”，Layout 块消失
transition + transform 的正确写法
不是加了 transform 就自动流畅——写错照样卡顿、跳变、起点漂移。
- 初始状态必须显式声明
transform: translate(0, 0)，不能依赖默认none -
transition必须写在基础选择器里，比如.menu { transition: transform 0.3s ease; }，不能只写在@media或:hover里 - 避免混用：
top: 50px; transform: translateY(20px)→ 最终下移 70px，且 layout 和 composite 节奏不同步，首帧易闪 - 移动端亚像素抖动常见于小数值动画（如
0.3px步进），可改用translate3d(0, 0, 0)强制启用 3D 上下文绕过
容易被忽略的硬件加速细节
光写 transform 不等于 GPU 加速生效。某些上下文会让浏览器降级回软件渲染：
- 父容器有
overflow: hidden时，translate可能因亚像素渲染导致边缘意外裁切，可加will-change: transform或微调top补偿 -
will-change: transform别滥用——它会提前分配图层内存；只对明确持续动画的元素设置，且动画结束及时清除（例如用 class 切换控制） - 多个
transform声明会相互覆盖：transform: rotate(10deg)后再设transform: translateX(20px)，旋转就丢了；必须合并为transform: rotate(10deg) translateX(20px)
真正难的不是写出 transform: translate() 这一行，而是判断这个元素动起来时，是否真的需要绕开布局流水线——如果只是 hover 显隐、点击展开，top/left 加 transition 已经足够；只有当它要随滚动实时位移、或每秒更新几十次时，才值得引入 transform 和图层管理逻辑。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
