translate性能优于top/left，因其不触发重排重绘，仅由GPU处理合成层视觉偏移；而top/left是布局属性，每帧强制执行Layout→Paint→Composite全流程，实测3秒动画累计Layout耗时约80ms，translate仅约8ms。
因为 left 是布局属性，每次修改都强制浏览器走 Layout → Paint → Composite 全流程；transform: translate() 只改合成层坐标，由 GPU 处理，主线程几乎不参与。
为什么 left 每帧都要重排
浏览器必须重新计算该元素在文档流中的几何位置：父容器会不会被撑开？兄弟元素要不要位移？z-index 层叠是否受影响？哪怕元素是 position: absolute，Chrome 125+ 和 iOS Safari 17+ 仍会执行轻量 Layout（实测 1–3ms/帧）。滚动中叠加多个 left 动画，主线程立刻吃紧。
-
top: 100px→ 浏览器重算盒模型、流式布局、渲染边界 - DevTools Performance 面板里能看到密集黄色
Layout块 - 同个 3 秒动画，
left方案累计 Layout 耗时约 80ms，translate仅约 8ms
为什么 translate 能跳过 Layout
transform: translate() 不改变 DOM 几何信息，只告诉合成器“把这个图层往 X/Y 方向挪 N 像素”。浏览器自动为其创建独立合成层，只要没被 filter 或 backdrop-filter 打断，就全程由 GPU 处理视觉偏移。
- 主线程 CPU 时间趋近于 0，GPU 持续输出稳定帧
- DevTools 中只看到绿色
Composite Layers，没有黄色Layout - 滚动中叠加多个
translate动画，仍可稳定维持 60fps
常见错误写法让优化失效
写了 transform 不等于性能就上去了。以下情况会让它悄悄降级回 CPU 渲染：
立即学习“前端免费学习笔记（深入）”；
- 混用
left和transform：最终位置是两者叠加，且整段动画降级 -
transform元素上同时存在filter: blur(2px)或backdrop-filter：图层无法被 GPU 合成 - 动画过程中 JS 频繁读取
offsetTop或getBoundingClientRect()：强制同步重排，打断流水线 - 父容器写了
will-change: transform，子元素也在做transform动画：图层嵌套爆炸，低端机内存吃紧
移动端特别注意的细节
iOS Safari 对亚像素 translateX(0.3px) 有轻微抖动，这不是 bug，而是 WebKit 合成器对 2D transform 的精度取舍。
- 解法：改用
transform: translate3d(0, 0, 0)强制启用 3D 上下文 - 点击错位更隐蔽：视觉上元素被移动了，但触摸响应仍落在原始盒边界上，尤其当父容器有
scale()或rotate()时 - 验证方法：DevTools 切换设备模式 → 开启
Show hit test borders
真正难的不是把 left 替换成 translate，而是确保整个动画链路里没有一次 Layout 触发、没有一个非合成属性混入、也没有一次同步布局读取——这些细节漏掉一个，性能就回到原点。
