transform位移比position（top/left）快一个数量级，因前者仅触发GPU合成、跳过Layout/Paint，帧耗时1–3ms；后者每帧强制重排，耗时20–30ms，且混用会导致起点跳变与交互错位。
直接说结论：transform 位移比 position（top/left）快一个数量级，不是“稍快”，而是动画帧耗时从 20–30ms 降到 1–3ms——卡顿和流畅的分界线就在这里。
为什么 top/left 每帧都触发 Layout
top 和 left 是布局属性，浏览器必须把它当“真实坐标”来校验：父容器会不会被撑开？兄弟元素要不要重排？z-index 层叠顺序是否受影响？哪怕元素是 position: absolute，现代 iOS Safari 和 Chrome 仍会执行轻量 Layout（实测 1–3ms/帧），滚动中叠加多个动画，主线程立刻吃紧。
DevTools Performance 面板里能看到密集黄色 Layout 块；同个 3 秒动画，top 方案累计 Layout 耗时约 80ms，transform 方案仅约 8ms。
- 改
top: 100px→ 浏览器重算盒模型、流式布局、渲染边界 - 动画期间每帧走 Layout → Paint → Composite 全流程，CPU 持续高负载
- 即使加了
will-change: top，也无法绕过 Layout 阶段
为什么 transform 只走 Composite
transform: translate() 不改 DOM 几何信息，只告诉合成器：“把这块图层像素往 X/Y 挪 N 像素”。原始位置、尺寸、文档流关系全保持不变，浏览器跳过 Layout 和 Paint，直接交由 GPU 合成输出。
立即学习“前端免费学习笔记（深入）”；
它自动触发图层提升（前提是没被 filter 或 opacity 降级），主线程几乎不参与，帧率稳定在 60fps 边缘。
- 确保独立图层：用
transform: translateZ(0)或translate3d(0, 0, 0)显式触发，兼容性好、无副作用 - 别滥用
will-change: transform：只在 JS 动画开始前 set，结束立即 remove，否则图层碎片化、内存升高 - 检查 DevTools Layers 面板，确认动画元素确实生成了独立图层（Layer）
混用 top 和 transform 会直接破坏动画逻辑
写 top: 50px; left: 100px; transform: translateY(20px)，最终位移 = 50px + 20px，但两者的计算节奏不同步：Layout 阶段算 top，Composite 阶段算 transform。结果就是起点跳变、动画闪一下再动。
典型现象：hover 时元素从左上角“闪”到目标位置才开始过渡——因为初始 transform 是 none，而你视觉上以为它已就位。
- 修复方式：归零
top/left，全部位移用transform表达，例如top: 0; left: 0; transform: translate(100px, 50px) - JS 控制时，避免
el.style.top = '100px'，统一用el.style.transform = 'translate(100px, 0)' - 若需精确点击响应（比如按钮），注意 translate 后 hit area 可能错位，尤其父级有
scale()或rotate()时
移动端还有两个隐藏坑
iOS Safari 对 translateX(0.3px) 这类亚像素步进有轻微抖动，不是 bug，是 WebKit 合成器对 2D 精度的取舍；同时，触摸响应区域仍落在原始盒边界，视觉位移 ≠ 交互区域位移。
- 抖动解法：改用
transform: translate3d(0, 0, 0)，强制启用 3D 上下文绕过限制 - 点击错位验证：DevTools 切换设备模式后打开 “Show hit test borders” 查看实际响应区域
- 不要指望
touch-action: none解决根本问题，它只是防手势误判
真正难的不是“知道该用 transform”，而是改完后要同步调整初始定位逻辑、验证图层是否真被提升、检查交互区域是否偏移——这些细节漏掉一个，性能优势就白费了。
