掉帧主因是使用top/left/width等触发重排的属性，而非硬件加速未开启；正确做法是仅用transform和opacity，配合动态will-change及Layer Borders验证GPU合成层。
掉帧不是因为“没开硬件加速”，而是你用了 top、left、width 这类会触发重排的属性——浏览器被迫在主线程反复计算布局，低端安卓机（尤其是 Android 5–7 WebView）直接卡死。
为什么 top/left 动画必掉帧
改 top 或 left 会强制触发重排（reflow）：浏览器得重新算位置、尺寸、换行、文本流……这个过程纯 CPU 跑，且必须串行。实测一次重排耗时 3–8ms，远超 16.67ms 的 60fps 帧间隔。动画一动，主线程就堵死，帧率断崖式跌到 15–20fps。
transform: translateX(100px) 完全不同：它只挪图层，由 GPU 合成线程处理，不碰布局、不重绘、不阻塞主线程。
- 错：
transition: left 0.3s→ 整条过渡降级为 CPU 渲染 - 对：
transition: transform 0.3s→ 且 JS 或 class 切换时，只改transform，不混top、margin、width - @keyframes 里哪怕加一个
box-shadow或background-color，整段动画就默默掉帧
transition: all 是定时炸弹
它不会报错，但只要某次意外改了 color、margin 或 border-radius，整条过渡就退回 CPU 渲染。浏览器不会警告，帧率却会悄悄崩。
立即学习“前端免费学习笔记（深入）”；
- 禁用：
transition: all 0.3s - 严格限定：
transition: transform 0.3s, opacity 0.3s - 确保初始态已声明，比如元素默认有
transform: translateX(0)，否则 hover 时会跳变
will-change 不是保险丝，是定时器
will-change: transform 只是提示浏览器“马上要动”，不是强制指令。静态写在 CSS 里（如 .item { will-change: transform; }），等于提前给每个元素占一块 GPU 图层内存。一屏 20 个列表项，低端安卓机极易 OOM 卡死。
- 加的时机：用户 touchstart 后、动画 class 应用前那一帧，用 JS 设置
el.style.willChange = 'transform' - 删的时机：监听
transitionend后立刻设el.style.willChange = 'auto' - 兜底必须加：iOS Safari 对 ≤16ms 动画可能不触发事件，
setTimeout(() => el.style.willChange = 'auto', duration + 100)
验证是否真走 GPU 合成层
写了 transform、加了 will-change，不代表真加速。关键看浏览器是否建了独立合成层。
- 打开 Chrome DevTools → Rendering → 勾选 “Layer Borders”：有绿色边框才算真提层
- 没绿框？检查父容器是否设了
overflow: hidden或filter: blur(1px)—— 这些会抑制子元素提层 - 动画中调一次
getBoundingClientRect()、offsetHeight或getComputedStyle()，就会强制同步 layout，直接破防
真正顺滑的前提，不是“加了什么”，而是“全程只走合成阶段”：不触发布局、不触发重绘、不偷偷读取任何布局信息——漏掉任意一点，再标准的 transform 也救不回来。
