频繁修改top/left会强制每帧重排，阻塞主线程；而transform:translate()由合成线程处理，跳过布局与绘制，实现GPU加速动画。
频繁改 top 或 left 会强制浏览器每帧都做重排（reflow），主线程直接被堵死，60fps 帧率根本保不住——这不是“有点卡”，是低端安卓机上滑动都粘滞的级别。
为什么 top/left 每次修改都触发重排
浏览器渲染流水线里，top 和 left 属于布局属性（layout properties）。只要它们一变，浏览器就得在主线程里重新计算：元素自身位置、周围兄弟节点的流式布局、文本换行、行高、甚至父容器高度……这个过程无法跳过，也不能交给 GPU。
实测在 Android 6–7 的 WebView 中，一次重排耗时稳定在 3–8ms，而 60fps 要求每帧 ≤16.67ms。动画若持续 300ms，中间可能触发 20+ 次重排，CPU 满载，帧直接丢一半。
transform: translate() 为什么能绕过重排
transform 是合成属性（compositing property），浏览器会把它单独拎进一个 GPU 图层，只做纹理移动或混合，完全跳过 Layout 和 Paint 阶段。
立即学习“前端免费学习笔记（深入）”；
- 改
transform: translateX(100px)→ 合成器线程处理，不碰 DOM 流 - 改
left: 100px→ 主线程立刻启动 layout 计算，所有依赖布局的样式都要重算 - 哪怕只在
@keyframes里混写一个left，整段动画就降级回 CPU 渲染，浏览器不会报错，但帧率肉眼可见掉
常见误操作和对应修复
很多卡顿不是因为没加硬件加速，而是“以为加了，其实没生效”：
- 写了
transition: transform 0.3s，但 JS 里还在用el.style.left = '100px'→ 动画属性和实际修改不一致，transform根本没动 - 同时设了
top: 50px和transform: translateY(20px)→ 浏览器放弃图层提升，退回到软件渲染 - 用
getBoundingClientRect()或offsetTop在requestAnimationFrame里读取位置，再设transform→ 强制同步回流，打断渲染流水线 - 以为加了
will-change: transform就万事大吉 → 它只是提示分层，不能掩盖top修改本身带来的重排
怎么验证你真的走 GPU 合成了
别靠感觉，用 Chrome DevTools 实锤：
- 打开 Rendering 面板 → 勾选 “Layer borders”：绿色边框表示成功提升为独立合成层
- 勾选 “Paint flashing”：动画期间大面积红色闪烁，说明仍在重绘，
transform可能被其他属性拖累（比如box-shadow或filter） - Performance 面板录制滚动或动画 → 看主线程是否长时间阻塞，Layout 阶段是否频繁出现
真正卡住你的，往往不是“没开 GPU 加速”，而是某个被忽略的 top 赋值、一次意外的 offsetTop 读取，或者 @keyframes 里多写的那行 width。这些地方不清理干净，加再多 translateZ(0) 都没用。
