卡顿主因是误用will-change而非未开GPU加速；正确做法是在交互瞬间动态添加will-change: transform，动画结束立即移除，并确保动画属性仅用transform和opacity，再通过Chrome DevTools的Layer borders验证橙色边框是否出现。
卡顿不是因为没开 GPU 加速，而是开了但用错了地方——will-change 不是开关，transform 和 opacity 才是底线。其他所有优化都建立在这两个属性正确使用的前提上。
为什么加了 will-change: transform 动画反而更卡
浏览器把 will-change 当作提示，不是指令。它会据此提前创建独立合成层，但若元素根本不动、或只动一次就停，图层就白占 GPU 内存；在低端 Android 上容易引发合成器抖动甚至 OOM。
- 常见误操作：全局给列表项写
.item { will-change: transform; }，结果每个都升层，内存和上下文切换成本飙升 - 真正该做的：仅在交互触发瞬间（如
touchstart或mouseenter）动态加 class，动画结束（监听animationend或transitionend）立刻移除 - 示例：
.card.is-animating { will-change: transform; }，JS 控制element.classList.add('is-animating')→ 动画播放 →element.addEventListener('animationend', () => element.classList.remove('is-animating'))
响应式动画中哪些属性必须替换成 transform 和 opacity
响应式场景常伴随 viewport 变化、元素重排、媒体查询切换，此时任何触发布局的动画都会被放大卡顿。必须确保动画本身不参与 layout 计算。
-
left: 100px→ 改用transform: translateX(100px) -
top: 50px→ 改用transform: translateY(50px) -
width: 200px→ 若需缩放，优先用transform: scaleX(2)（注意transform-origin控制基准点） -
visibility: hidden或display: none不能用于过渡——前者跳变，后者让元素脱离渲染树，动画无效；应先设opacity: 0; visibility: visible;再过渡
如何验证 GPU 加速是否真实生效
写了 will-change、用了 transform，不代表真加速。必须用 DevTools 看底层行为。
立即学习“前端免费学习笔记（深入）”；
- Chrome DevTools →
Cmd+Shift+P输入 “Rendering” → 勾选Paint flashing和Layer borders - 动画期间只有绿色闪动（paint）→ 说明仍在 CPU 渲染，没走合成
- 能看到橙色边框包裹元素 → 表示已提升为独立合成层，
transform/opacity正常生效 - 若某元素本该加速却没出现橙色边框，检查是否被父级的
transform: none或will-change: auto抑制了层提升
最常被忽略的一点：响应式动画卡顿，往往发生在媒体查询切换后 DOM 重排完成前，就急着触发动画。这时候哪怕属性全对，也会被主线程阻塞拖累。务必确认动画是在 layout 完成后、通过 requestAnimationFrame 触发样式变更，而不是靠 setTimeout 模拟延迟。
