加 will-change 动画反而更卡，因其仅是提示而非强制加速，滥用会导致图层过多、内存飙升、合成器抖动；应仅对即将动画的元素动态添加并立即移除，配合 transform/opacity 属性及 DevTools 验证图层是否真实生成。
为什么加了 will-change 动画反而更卡
加 will-change: transform 不等于“开加速”，它只是个提示，浏览器按需响应。如果元素根本没动、或只动一次就停，提前升层会白占 GPU 内存，尤其在低端 Android 上容易引发合成器抖动甚至 OOM。常见误操作是全局给所有动画元素写 will-change: transform，比如列表项 .item 批量声明，结果每个都建独立图层，内存和上下文切换成本飙升。
真正该做的：只对「即将开始动画」的元素，在交互触发瞬间（如 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'))
页面切换时卡顿，大概率不是动画本身的问题
页面切换（比如 SPA 路由跳转、模态框弹出）常伴随大量 DOM 插入/移除、样式重算、布局重排。此时即使动画用了 transform，也会被主线程阻塞拖累。关键要区分“动画卡”和“切换卡”：
立即学习“前端免费学习笔记（深入）”；
- 若切换瞬间掉帧，优先检查 JS 是否同步执行耗时逻辑（如未节流的
scroll监听、未延迟的数据渲染） - 若动画在切换后才启动但延迟明显，说明 class 切换被卡在事件队列里——别用
setTimeout模拟延迟，改用requestAnimationFrame触发样式变更 - 避免在切换过程中同时触发多个动画（如新页面元素入场 + 旧页面淡出 + 导航栏缩放），错峰启动或限制可视区动画数量
transform 和 opacity 是底线，will-change 是可选补丁
动画是否流畅，第一道关是属性选择。只要还在用 left、top、width、height 或 background-color 做动画，加再多 will-change 都救不回来。这些属性强制触发布局 → 绘制 → 合成全流程，CPU 压力大。
必须替换为：
-
left: 100px→transform: translateX(100px) -
opacity动画没问题，但别混用visibility: hidden或display: none—— 后者会让元素脱离渲染树，动画无效 - 缩放/旋转统一走
transform: scale(1.2) rotate(15deg)，注意transform-origin控制基准点
will-change 只在以下场景值得加：复杂多阶段动画（如侧滑菜单+遮罩+内容位移）、或已确认 Chrome DevTools 的 Layers 面板里该元素没自动升层（无橙色边框）时，作为兜底提示。
验证是否真走 GPU 加速，别靠感觉
“看起来顺”不等于真加速。打开 Chrome DevTools → 快捷键 Cmd+Shift+P（Mac）或 Ctrl+Shift+P（Win）→ 输入 “Rendering” → 勾选两项：
-
Paint flashing：动画期间大面积绿色闪动 = 还在 CPU 渲染，没走合成 -
Layer borders：看到橙色边框包裹目标元素 = 已提升为独立合成层
如果该有橙色边框却没有，检查父容器是否写了 transform: none 或 will-change: auto 抑制了层提升；或者子元素用了 filter: blur() 等高开销属性，导致浏览器放弃合并图层。
真正卡顿的根源，往往不是“没开硬件加速”，而是“浏览器被逼着干了太多不该干的活”。聚焦属性选择、控制图层规模、分离动画与 DOM 操作节奏，比盲目堆 will-change 有效得多。
