改top/left必然触发重排，因其属布局属性，浏览器须在主线程重新计算元素及关联节点的位置、尺寸等，单次耗时3–8ms；而transform: translate()仅走GPU合成线程，跳过Layout与Paint。
为什么改 top/left 必然触发重排（reflow）
因为 top 和 left 是布局属性（layout property），浏览器必须重新计算该元素在文档流中的精确位置、尺寸、换行、文本包裹，以及所有受影响的祖先和兄弟元素——这个过程叫重排，全程跑在主线程，无法交给 GPU。
哪怕只把 left 从 10px 改成 11px，浏览器也得遍历 layout 树，单次耗时在低端安卓机（Android 5–7 WebView）上常达 3–8ms，而 60fps 要求每帧 ≤16.67ms。一卡就是必然。
top/left 和 transform: translate() 渲染路径完全不同
前者走完整渲染流水线：Style → Layout → Paint → Composite，CPU 全包；后者跳过前两步，只走 Composite，由 GPU 合成线程独立处理位移矩阵，不干扰主线程。
常见错误写法会悄悄降级：
立即学习“前端免费学习笔记（深入）”；
-
transition: left 0.3s, background-color 0.3s→ 整条 transition 回退到 CPU 渲染 -
transform: translateX(100px); left: 20px共存 → 浏览器放弃优化，仍触发重排 -
will-change: left→ 完全无效，will-change只对transform和opacity有预分配图层作用
移动端动画卡顿的典型现场与修复动作
你看到“一卡一卡”“手指滑动粘滞”“动画中途跳变”，大概率不是 JS 写错了，而是 CSS 属性选错了。
实操建议：
- 位移统一用
transform: translateX()/translateY()，别碰top/left/margin - 初始定位也用
transform，比如transform: translate(30px, 20px)，而非靠top/left布局 - 动画中禁止读取
offsetTop、getBoundingClientRect()等布局信息，否则强制同步重排 - 用 Chrome DevTools 的
Layers面板验证：动画元素是否真被提升为独立合成层？没提升＝白优化
为什么 position: absolute 也不能保你流畅
很多人以为加了 position: absolute 就脱离文档流、动画就一定快——错。脱离文档流 ≠ 脱离布局计算。只要改的是 top 或 left，浏览器仍需重新确认该元素相对于其 containing block 的几何位置，照样触发重排。
真正起效的是属性本身是否属于合成层：只有 transform 和 opacity 被现代渲染管线明确标记为「可合成」。其他一切，包括 box-shadow、filter、border-radius，哪怕只混进一个关键帧，整段动画就掉帧。
复杂点在于：图层提升不是自动的，也不是永久的。它依赖条件满足（如无 overflow: hidden 干扰、父级没非 identity transform）、生命周期可控（will-change 得及时设回 auto），且必须用工具验证——不看 Layers 面板，等于闭眼调优。
