最有效手段是用transform替代left/top/width等属性，因其将动画卸载至GPU合成线程，避开重排与重绘；混入非合成属性或JS读取布局信息会导致降级卡顿。
直接用 transform 替代 left、top、width 等属性，是解决 transition 卡顿掉帧最有效、改动最小的手段——它让动画从 CPU 主线程卸载到 GPU 合成线程，彻底避开重排（reflow）和重绘（paint）。
为什么 transition: left 0.3s 会掉帧，而 transform 就很稳
浏览器对 left、top、margin 这类属性的修改，每帧都要重新计算整个文档流的位置、尺寸、换行、文本布局……这个过程叫重排，全靠 CPU 干活。低端安卓机（尤其 Android 5–7 WebView）调度弱，一帧内反复重排，主线程瞬间卡死。
而 transform: translateX(100px) 只是挪动已有图层，GPU 合成线程直接处理，不碰布局也不重绘。
-
transition: left 0.3s→ 整条过渡降级回 CPU 渲染 -
transition: transform 0.3s→ 且只改transform，别混top或margin - 位移统一用
transform: translate(30px, 20px)，不是top/left组合 - 缩放用
transform: scale(0.9)，旋转用rotate(45deg)，别碰width/height
transition 中必须显式声明 transform，不能写 all
transition: all 0.3s ease 像定时炸弹：某次 hover 意外触发了 color 或 border 变化，整段动画就悄悄退回到 CPU 渲染。
立即学习“前端免费学习笔记（深入）”；
- 正确写法：
transition: transform 0.3s cubic-bezier(0.25, 0.46, 0.45, 0.94) - 如果同时做位移+缩放，仍只需写一次
transform，内部多个函数共用同一过渡逻辑 - 绝对不要写
transition: left, transform 0.3s—— 混入非合成属性等于放弃 GPU 加速 - 旧浏览器（如 IE11、Android 4.4 WebView）对
translateX()支持不稳定，优先用translate3d(0, 0, 0)触发图层提升
如何确认 GPU 加速真的生效了
写了 transform: translateZ(0) 不等于就加速了。关键得看浏览器是否真建了独立图层。
- 打开 Chrome DevTools → Rendering 面板 → 勾选 “Layer Borders”：有绿色边框的元素才是被提升的合成层
- 没绿框？检查父容器是否设了
overflow: hidden或filter: blur(1px)—— 这些会抑制子元素提层 - 避免在动画元素上同时用动态
box-shadow或filter，它们可能让图层合并失败，退回到 CPU 渲染 -
will-change: transform是提示，不是开关；静态全局加（如* { will-change: transform; }）等于提前塞满 GPU 内存，安卓低端机容易 OOM
JS 控制时最容易忽略的隐性退化点
即使所有 CSS 都写对了，只要动画过程中 JS 偷偷调了一次 getBoundingClientRect()、offsetWidth 或 computedStyle，就会强制同步 layout，打断 GPU 流水线。
- 不要在
transitionstart回调里读取布局信息 - 避免在
touchstart中连续设置多个样式再读尺寸 - 用
requestAnimationFrame包裹读操作，且确保“先批量写，下一帧再读” - iOS Safari 对 ≤16ms 的动画可能不触发
transitionend，务必加兜底：setTimeout(() => el.style.willChange = 'auto', duration + 100)
真正卡顿的根源往往不在 transform 写得对不对，而在于你有没有在动画进行中“偷偷干了别的事”——比如读布局、改非合成属性、或让父容器意外截断图层提升。
