为什么CSS transition使用will-change后仍然卡顿

will-change没起效是因为动画属性未走合成路径；仅transform、opacity等少数属性有效，left/width等声明被忽略，且必须动态设置并用双requestAnimationFrame清除，静态声明已失效。

will-change没起效，是因为动画属性根本不在合成路径上

加了 will-change: transform 但动画还是卡，大概率是动画本身没用 transform 或 opacity。浏览器只对这两个属性（以及极少数如 scroll-position）响应 will-change 提示；对 left、width、border-radius 等声明，直接忽略——你写的那行 CSS 实际无效。

常见错误包括：

1. 写了 will-change: transform，但过渡目标却是 left: 100px —— 浏览器仍要每帧重排
2. 用 transition: all 0.3s，其中混入了 background-color 或 box-shadow —— 这些属性强制走 CPU 绘制，拖垮整个动画线程
3. 元素父容器有 overflow: hidden + border-radius，导致子元素无法独立图层化，will-change 失效

图层创建失控，GPU 内存被提前占满

will-change 不是“开启加速”，而是“申请图层”。浏览器为每个启用它的元素分配独立合成层，占用 GPU 内存和纹理缓存。一屏 20 个列表项全写 .item { will-change: transform; }，等于常驻 20+ 图层，低端安卓机立刻掉帧、发热、甚至 WebView 崩溃。

真正该做的不是静态声明，而是动态控制：

1. 只在用户真实交互瞬间设置：element.addEventListener('touchstart', () => element.style.willChange = 'transform')
2. 动画结束必须设为 'auto'（不是空字符串）：element.addEventListener('transitionend', () => element.style.willChange = 'auto')
3. 避免用 scroll 事件触发 —— 节流稍慢就会堆积未清理状态

DevTools 里看不到橙色边框，说明加速根本没生效

写了 will-change、用了 transform，不代表真加速。必须验证底层行为：

1. Chrome DevTools → Cmd+Shift+P 输入 “Rendering” → 勾选 Layer borders：看到橙色边框才表示图层已创建
2. 同时勾选 Paint flashing：如果动画区域外也高频绿色闪烁，说明重绘范围失控，will-change 解决不了
3. Performance 面板录制动画过程：若 Layout 或 Update Layer Tree 占比高，问题不在合成层，而在主线程被 JS 或样式读取阻塞

移动端 touch 事件没配 passive: true，手势根本不跟手

很多卡顿不是渲染问题，而是事件阻塞。iOS Safari 和 Android Chrome 默认对 touchstart/touchmove 同步等待主线程空闲，导致动画延迟半拍。即使 will-change 设置正确，也会感觉“粘滞”。

必须显式声明：

1. 监听时加 { passive: true }：element.addEventListener('touchstart', handler, { passive: true })
2. 配合 touch-action: pan-y（纵向滚动）或 manipulation（保留点击），让浏览器跳过双击判定延迟
3. 滚动中避免在 touchmove 回调里读取 scrollTop 或 getBoundingClientRect() —— 强制同步回流，一滚就掉帧

关键点始终没变：will-change 是预告，不是保险丝；它只在 transform/opacity 动画真实发生时才起作用，且生命周期必须由 JS 精确控制。写死在 CSS 里，等于默认开启内存泄漏模式。