直接用transform替代left/top/width等属性是解决移动端动画卡顿最有效、最低成本的手段——它让动画从CPU主线程卸载到GPU合成线程，避开重排和重绘；transform和opacity是仅有的两类能稳住60fps的合成属性，混入其他属性或JS读取布局信息均会导致降级。
直接用 transform 替换 left/top/width 等属性，是解决移动端动画卡顿最有效、最低成本的手段——它让动画从 CPU 主线程卸载到 GPU 合成线程，避开重排（reflow）和重绘（paint）。
为什么 transform 能稳住 60fps
移动端卡顿绝大多数源于浏览器反复执行重排：每次改 left 或 top，就得重新计算整个文档流的位置、尺寸、换行，低端安卓机（尤其 Android 5–7 WebView）一帧内多次重排，主线程直接堵死。而 transform: translateX(100px) 只是挪动已有图层，GPU 直接合成，不碰布局也不重绘。
关键点在于：transform 和 opacity 是仅有的两类能走合成线程的 CSS 属性。其他任何属性——哪怕只混进一个 box-shadow 或 background-color ——整段 @keyframes 或 transition 都会降级回 CPU 渲染。
transition 中必须只写 transform，不能写 all
常见错误是写 transition: all 0.3s ease，结果鼠标 hover 时连 color 或 border 都被强制加过渡，触发无谓重绘。正确做法是显式限定：
立即学习“前端免费学习笔记（深入）”；
-
transition: transform 0.3s cubic-bezier(0.25, 0.46, 0.45, 0.94)（推荐缓动曲线，比ease更自然） - 如果同时做位移+缩放，写成
transition: transform 0.3s即可，transform是单一属性名，内部多个函数（translate、scale、rotate）共用同一过渡逻辑 - 绝对不要写
transition: left, transform 0.3s—— 混入非合成属性等于放弃 GPU 加速
什么时候需要 translate3d(0,0,0) 或 will-change
translate3d(0,0,0) 和 will-change: transform 都是为了“强制提升图层”，但它们不是必选项，更不是越早加越好：
- 多数简单动画（单个按钮 hover、卡片滑入）只用
transform+transition就足够流畅，无需额外 hack -
translate3d(0,0,0)在老版 Android WebView 中仍有兜底价值，但现代 Chrome/Safari 已基本不需要；它可能增加内存占用，慎用于列表项 -
will-change必须动态控制：在touchstart时通过 JS 设置el.style.willChange = 'transform'，监听transitionend后立刻设为'auto'；静态写在 CSS 里（如.item { will-change: transform; }）极易引发图层爆炸，低端机直接 OOM 卡死
容易被忽略的细节：JS 读取布局信息会悄悄破坏优化
即使你所有 CSS 都写对了，只要动画过程中 JS 偷偷调了一次 getBoundingClientRect()、offsetTop 或 getComputedStyle(el).height，浏览器就会立刻退回到重排流程，帧率断崖下跌——而且不报错、无提示。
排查方法：打开 Chrome DevTools → Rendering → 勾选 “Layout Shift Regions” 和 “FPS meter”，边操作边观察；若动画中突然出现大片红色区域或 FPS 掉到 20 以下，大概率是 JS 触发了同步布局计算。
真正安全的动画，是纯 CSS 驱动、不依赖 JS 读取任何布局值、且所有过渡属性严格限定在 transform 和 opacity 范围内。其余所谓“优化技巧”，都是在补这个基础没做牢的洞。
