移动端动画卡顿应优先使用 transform 和 opacity 替代 left、top 等触发重排的属性；will-change 需动态控制，仅动画前设置、结束后清除；验证 GPU 渲染需借助 Chrome DevTools 的 Paint flashing、Layer borders 和 FPS meter。
用 transform 和 opacity 替代 layout 属性动画
移动端卡顿最常见原因是用了 left、top、width、height、margin 这类会触发重排（reflow）的属性。浏览器每帧都得重新计算布局，低端机直接掉帧。
真正安全的只有 transform 和 opacity：它们只走合成（compositor）线程，由 GPU 处理，不碰主线程的 layout/paint。
- 位移动画：把
left: 100px改成transform: translateX(100px) - 缩放/旋转：统一用
transform: scale(1.2)或rotate(45deg)，别调width/height - 显隐切换：用
opacity: 0+pointer-events: none，别用display: none或visibility: hidden - 避免混用：不要在同一个
transition里同时写width和opacity，浏览器可能降级到 CPU 渲染
will-change 不是开关，是“预告”，必须动态控制
will-change: transform 不是贴上就变快，它会让浏览器提前创建独立图层、分配 GPU 内存。元素不动却一直挂着，等于白占资源，还可能引发重绘抖动。
正确做法是只在动画即将开始前一刻设置，结束后立刻清除。
立即学习“前端免费学习笔记（深入）”；
- JS 中监听
touchstart或mouseenter，添加 class 如.is-animating，CSS 里写.is-animating { will-change: transform; } - 动画结束时（监听
animationend或transitionend），同步移除该 class - 绝对不要全局写
.card { will-change: transform; }—— 列表页里上百个卡片全建图层，内存爆炸风险很高 - 复杂交互动画（如下拉刷新）可配合
requestIdleCallback延迟移除，避免和主线程争抢
验证是否真走 GPU 渲染，别靠肉眼判断
看起来“顺”不等于性能好。很多卡顿根源根本不在动画本身，比如图片未压缩、JS 执行阻塞、阴影太多，加了 will-change 也救不了。
打开 Chrome DevTools → Rendering 面板，实测才是关键：
- 勾选
Paint flashing：动画期间大面积绿色闪烁 = 频繁重绘，说明没走 GPU，得查是不是用了box-shadow、background-color等属性 - 勾选
Layer borders：看到细边框才表示生成了预期合成图层；如果满屏都是边框，就是图层爆炸（layer explosion） - 配合
FPS meter观察曲线：持续低于 50fps 就得定位瓶颈，不是所有问题都出在 CSS 动画上
硬件加速要轻量触发，慎用 translateZ(0)
transform: translateZ(0) 或 translate3d(0, 0, 0) 是比 will-change 更轻量的 GPU 加速触发方式，兼容性更好，副作用更小。
但它也不是无代价的——每个启用的元素都会被提升为独立图层。用多了照样吃内存，尤其在滚动区域或列表项里批量加，风险明显。
- 仅对明确需要持续动画的容器使用，比如轮播图外层、侧滑菜单根节点
- 避免在
.item这类可复用组件上直接写死transform: translateZ(0) - 如果父容器已设
overflow: hidden，子元素再加transform可能在某些安卓机型上强制回退到 CPU 渲染，需实测
@keyframes 的问题，而是父级意外加了 perspective 导致 iOS WebKit 解析异常，或者没写 transform-origin: center 触发了隐藏 bug。优化前先测，测完再动。 
