浏览器卡顿主因是动画触发重排重绘，改用transform/opacity可提升至GPU合成层渲染；需验证绿色图层边框、慎用will-change、避免动画中同步读取布局或修改非合成属性。
掉帧卡顿不是浏览器“不行”，而是你让浏览器做了太多它不擅长的事——比如一边跑动画一边反复重排布局。只要把动画属性换成 transform 和 opacity，90% 的过渡卡顿会直接消失。
为什么 transition: left 0.3s 会掉帧，而 transform: translateX 却很稳
浏览器对 left、top、width 这类属性的修改，每帧都要重新计算文档流（layout）、重绘像素（paint），CPU 跑满也难保 60fps；而 transform 和 opacity 属于合成属性（compositing），浏览器会把它们单独拎进一个 GPU 图层，只做纹理移动或混合，不碰布局和绘制。
- 错误写法：
transition: left 0.3s, background-color 0.3s;—— 只要其中任一属性非合成，整条过渡就降级到 CPU 渲染 - 正确写法：
transition: transform 0.3s, opacity 0.3s;—— 且确保 JS 或 class 切换时，只改这两个属性 - 别信
transition: all 0.3s：它像定时炸弹，某次意外改了margin或color，动画就悄悄变卡
如何确认 GPU 加速真的生效了
写了 transform: translateZ(0) 不等于就加速了。关键得看浏览器是否真建了独立图层。
- 打开 Chrome DevTools → Rendering 面板 → 勾选 “Layer Borders”：有绿色边框的元素才是被提升的合成层
- 如果没绿框，检查父容器是否设了
overflow: hidden或filter: blur(1px)—— 这些会抑制子元素提层 - 避免在动画元素上同时用
box-shadow（尤其是动态变化的）或filter，它们可能让图层合并失败，退回到 CPU 渲染
will-change 是提示，不是开关，用错反而更卡
will-change: transform 只是告诉浏览器“这个元素接下来可能动”，不是强制指令。静态全局加，等于提前给所有元素塞进 GPU 内存。
- 推荐做法：JS 中动画开始前 1–2 帧设置
el.style.willChange = 'transform'; - 监听
transitionend后立刻清除：el.style.willChange = 'auto'; - iOS Safari 对极短动画（≤16ms）可能不触发
transitionend，加兜底：setTimeout(() => el.style.willChange = 'auto', duration + 100) - 绝对不要写：
* { will-change: transform; }或.list-item { will-change: transform; }—— 安卓低端机容易 OOM
移动端最容易忽略的隐性退化点
你以为用了 transform 就高枕无忧？实际中，很多卡顿发生在“动画进行中偷偷干了别的事”：
- JS 里调用了
getBoundingClientRect()、offsetHeight等会强制同步 layout 的 API - 动画过程中又改了
width、display、z-index等非合成属性 - 滚动监听里频繁 toggle 动画 class，没做节流，导致图层反复创建销毁
- 用
translate3d(0, 0, 0)强提层在 iOS 15+ 反而可能引发闪烁，优先用语义清晰的translateY(0)或opacity: 0.99（某些安卓机型对opacity: 0会跳过图层创建）
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
