transform: translate() 性能优于 top/left，因前者不触发重排重绘、仅走GPU合成层，后者强制浏览器每帧执行Layout→Paint→Composite流程；正确用法需归零top/left再用translate表达全部位移，并注意移动端亚像素抖动及will-change滥用问题。
因为 transform: translate() 不触发浏览器重排（reflow）和重绘（repaint），而 top/left 会——这是性能差距的根本原因。
为什么 top/left 会强制重排
修改 top 或 left 时，浏览器必须重新计算该元素在文档流中的几何位置，连带影响其父容器尺寸、兄弟元素布局，甚至触发整棵 DOM 树的 layout 阶段。哪怕元素已是 position: absolute，Chrome 和 Safari 仍会在部分版本中执行轻量级 layout（实测约 1–3ms/帧），尤其在动画密集时叠加明显。
-
top: 100px是“真实位移”，改变盒模型坐标，引擎必须校验 margin/padding/border 是否导致父容器撑开 - 动画过程中每帧都走 Layout → Paint → Composite 流程，CPU 负载高
- DevTools Performance 面板里能看到大量黄色 Layout 块，帧率易跌破 60fps
为什么 translate 只走合成层
transform: translate() 不改布局信息，只告诉 compositor：“把这个图层往 X/Y 方向挪 N 像素”，由 GPU 直接处理视觉偏移。元素原始位置、尺寸、文档流关系全部保持不变。
- 浏览器自动为其创建独立的合成层（compositing layer），只要没被其他属性（如
filter）打断 - 动画期间主线程几乎不参与，CPU 时间趋近于 0，GPU 持续输出稳定帧
- 实测同个 3 秒动画：
top方案累计 layout 耗时约 80ms，translate仅约 8ms
常见误用：以为加了 position 就安全
很多人写 position: absolute; top: 0; left: 0; 后，只把动画部分换成 transform: translateX(100px)，却忽略初始定位逻辑未同步调整——这会导致视觉错位或动画起点漂移。
立即学习“前端免费学习笔记（深入）”；
- 错误做法：
top: 20px; left: 30px;→ 动画只改transform，但初始偏移仍靠top/left，两者叠加 - 正确做法：先把
top/left归零（top: 0; left: 0;），再用transform: translate(30px, 20px)表达全部位移 - 若父容器无
position: relative，absolute子元素会脱离预期上下文，translate也救不回来
移动端特别注意：subpixel 渲染抖动
iOS Safari 对 translateX 的亚像素渲染存在轻微抖动，尤其在小数值动画（如 0.3px 步进）中明显。这不是 bug，而是 WebKit 合成器对 2D transform 的精度取舍。
- 解决方案：改用
transform: translate3d(0, 0, 0)，强制启用 3D 上下文，绕过该限制 - 别滥用
will-change: transform—— 只在动画开始前 set，结束立即 remove，否则长期占用内存与图层资源 - 避免同时对
transform和opacity做同一transition，某些旧版 Safari 会退化回 CPU 渲染
真正难的不是记住“用 translate”，而是每次写定位时，下意识区分：这里是要改变布局，还是仅改变视觉呈现？前者用 top/left，后者一律交给 transform。
