transform: translate() 性能优于 top，因其跳过重排与重绘，仅走 GPU 合成层；top 每帧强制 Layout，耗时高且易掉帧；需避免混合使用、显式限定 transition 属性，并慎用 DOM 读取。
因为 transform: translate() 不触发重排（reflow）和重绘（paint），而 top 会——这是性能差距的根源，不是“看起来更顺”，而是浏览器渲染流水线根本绕开了最耗时的两个阶段。
为什么 top 每帧都在强制重排
top 是布局属性（layout property），哪怕元素是 position: absolute，浏览器仍需在每次动画帧中确认：该偏移是否导致父容器高度变化？是否影响兄弟元素的 z-index 层叠顺序？是否改变 box-shadow 的渲染边界？这些都得走完整 Layout 流程。
- Chrome DevTools Performance 面板里会出现密集黄色 “Layout” 块，单帧 Layout 耗时常达 1–3ms（移动端尤其明显）
- 滚动中叠加多个
top动画，主线程很快饱和，帧率跌破 45fps 是常态 - 即使只改一个像素，也必须重新计算盒模型位置和文档流关系，无法跳过
为什么 translate 只走 GPU 合成层
transform: translate() 是合成属性（compositor property），它不改变元素在 DOM 中的几何信息，只告诉合成器：“把这张图层往 X/Y 方向挪 N 像素”。原始位置、尺寸、流内关系全部保持不变。
- 浏览器自动为其创建独立合成层（compositing layer），只要没被
filter或mask等属性打断 - 动画期间主线程几乎不参与，CPU 时间趋近于 0，GPU 持续输出稳定帧
- 实测同个 3 秒动画：
top方案累计 layout 耗时约 80ms，translate仅约 8ms
常见误用：混合 top 和 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)' - 注意移动端亚像素抖动：iOS Safari 对
translateX(0.3px)步进有轻微抖动，可用translate3d(0, 0, 0)绕过
transition 和 animation 中必须显式限定 transform
写 transition: all 0.3s ease 是典型陷阱——哪怕 hover 时只动了颜色，也会因混入非合成属性，整段过渡降级回 CPU 渲染。
- ✅ 正确：
transition: transform 0.3s cubic-bezier(0.25, 0.46, 0.45, 0.94) - ❌ 无效：
transition: left, transform 0.3s ease（混入left就等于放弃 GPU 加速） - 如果同时做位移+缩放，仍只需写
transition: transform 0.3s，内部多个函数共用同一过渡逻辑
真正难的不是写出 transform: translate() 这一行，而是判断这个动画是否真的需要绕开布局流水线——如果只是 hover 显隐、点击展开，top + transition 已经足够；只有当它要随滚动实时位移、或每秒更新几十次时，才值得引入 transform 和图层管理逻辑。另外，JS 动画中偷偷调一次 getBoundingClientRect()，就足以让所有优化失效。
