直接用transform和opacity做动画可大幅提帧，因二者仅触发GPU合成，不触发重排与重绘；而top、left等属性会强制执行layout→paint→composite全流程，单帧易超16ms导致掉帧。
直接用 transform 和 opacity 做动画，基本就避开了 90% 的卡顿问题；其他操作都是在补漏或应对边缘情况。
为什么只改 transform/opacity 就能大幅提帧
浏览器渲染流水线中，transform 和 opacity 变化不会触发 layout（重排）和 paint（重绘），只走 composite（合成）阶段——这个阶段由 GPU 处理，开销极低。而 top、left、width、height、margin 等属性一动，就会强制重排，单帧耗时轻松突破 16ms，掉帧立刻出现。
- 移动端尤其敏感：重排计算在 CPU 上进行，小内存设备更容易卡顿
- 即使加了
transform: translateX(0)，也救不了left: 10px—— 因为left本身已触发布局计算 -
box-shadow和background-position在非硬件加速上下文中也会意外触发重绘
如何确认 GPU 加速真生效了
别信 will-change: transform 或 translateZ(0) 写了就完事。浏览器是否真建了独立合成层，得看 Layers 面板。
- Chrome DevTools → Layers 面板，过滤动画元素，确认它有独立图层（不是“Shared”或嵌套在父层里）
- 父容器若有
overflow: hidden、filter: blur()、clip-path或非transform: none的变换，会压制子元素的图层提升 - 更稳妥的触发写法是
transform: translate3d(0, 0, 0)，兼容性比translateZ(0)略好 -
will-change不要常驻：只在动画开始前 1–2 帧设为transform，结束后立即设回auto
animation-timing-function 卡顿的隐蔽原因
缓动函数本身不拖慢帧率，但它是“放大器”——一旦关键帧里混入非合成属性，整个动画就会降级为 CPU 渲染。
立即学习“前端免费学习笔记（深入）”；
- 例如：
@keyframes slide中同时写transform: translateX()和background-color: #fff，background-color触发重绘，GPU 加速失效 - 多个
@keyframes元素共用同一个父容器，而该容器有filter: blur(2px)，整块区域被迫合并在单层绘制，失去并行合成能力 - 避免
animation和transition同时控制同一属性（比如都动opacity），时机难对齐，易引发样式冲突与重绘
容易被忽略的兜底和边界条件
性能优化不是“加上 translate3d 就结束”，真实项目里最常翻车的是这些细节：
- 用
prefers-reduced-motion媒体查询禁用非必要动画，对系统开启“减少动画”的用户既是可访问性要求，也省下无谓的合成层开销 - 动画元素数量要克制：单页超过 10 个持续活跃的合成层，内存占用明显上升，iOS Safari 尤其吃紧
- 滚动容器（如
overflow-y: auto）内慎用will-change，容易导致滚动抖动或图层频繁重建 - JS 驱动动画必须用
requestAnimationFrame，setTimeout或setInterval无法对齐屏幕刷新节奏，60fps 是奢望
