transform: translate()性能优于top/left，因其不触发重排，仅走GPU合成层；而top/left强制每帧执行Layout→Paint→Composite全流程，实测3秒动画layout耗时约80ms vs 8ms。
因为 transform: translate() 不触发重排（reflow），而 top 会——这是性能差距的底层原因，不是“稍好一点”，而是渲染流水线级别的差异。
top/left 动画为什么强制重排
浏览器必须把 top 和 left 当作布局坐标来校验：父容器会不会被撑开？兄弟元素要不要位移？box-shadow 边界是否变化？哪怕元素是 position: absolute，Chrome 125+ 和 iOS Safari 17+ 仍会执行轻量级 layout（实测约 1–3ms/帧）。滚动中叠加多个动画，主线程立刻吃紧。
-
top: 100px→ 引擎重算盒模型、流式布局、渲染边界 - 每帧走 Layout → Paint → Composite 全流程，CPU 持续高负载
-
DevTools Performance面板里密集出现黄色Layout块
translate 为什么只走 GPU 合成层
transform: translate() 不改 DOM 几何信息，只告诉合成器（compositor）：“把这个图层往 X/Y 方向挪 N 像素”。元素原始位置、尺寸、文档流关系全部保持不变。浏览器自动为其创建独立合成层，只要没被其他属性（如 filter）打断。
- 主线程几乎不参与，CPU 时间趋近于 0
- 同个 3 秒动画：
top累计 layout 耗时约 80ms，translate仅约 8ms -
DevTools里只有绿色Composite Layers，无黄色Layout
absolute + translate 混用时最常踩的坑
常见错误不是“没用 translate”，而是保留 top: 20px; left: 30px，只把动画部分改成 transform: translateX(100px)——这会导致最终位置是两者叠加（下移 120px），且动画起点漂移。
立即学习“前端免费学习笔记（深入）”；
- 必须先归零：
top: 0; left: 0;，再用transform: translate(30px, 20px)表达全部位移 - JS 控制时，避免
el.style.top = '100px'，统一用el.style.transform = 'translate(100px, 0)' - 百分比行为不同：
top: 10%相对父容器高度，transform: translateY(10%)相对自身高度——不能直接替换
移动端特别要注意的细节
iOS Safari 对 translateX(0.3px) 这类亚像素步进有轻微抖动，这不是 bug，是 WebKit 合成器对 2D transform 的精度取舍；更隐蔽的是点击区域错位：视觉上元素被移动了，但触摸响应仍落在原始盒边界上——尤其当父容器有 scale() 或 rotate() 时。
- 抖动解法：
transform: translate3d(0, 0, 0)强制启用 3D 上下文 - 点击错位检查点：用
DevTools的 “Toggle device toolbar” + “Show hit test borders” 查看实际响应区域 -
will-change: transform别长期设置——只在动画开始前 set，结束立即 remove，否则低端机内存吃紧
真正难的不是写出 transform，而是确保它不被 filter、overflow: hidden、JS 同步读取或混用定位属性悄悄降级。一旦降级，性能反而更差。
