will-change 优化需精准预告、及时收场、属性合规：仅在交互瞬间（如 touchstart）动态添加，动画结束立即移除；仅对 transform 和 opacity 有效，须用 layers 面板验证图层生成。
要通过 will-change 提前触发合成层优化、缓解异步动画卡顿，关键不是“加了就加速”，而是精准预告 + 及时收场 + 属性合规。它不解决主线程阻塞，只减少动画启动时的合成准备延迟。
只对即将动画的元素，在交互瞬间设置
浏览器不会因 will-change 主动升层，而是在后续属性变化时参考该提示做优化。若提前太久设置（比如页面加载时就写死），图层会长期驻留，白占 GPU 内存，尤其在低端 Android 上易引发合成器抖动。
- ✅ 正确做法：在
touchstart、mousedown或mouseenter等用户意图明确的时刻，用 JS 动态添加含will-change的 class - ❌ 错误做法：全局给所有可能动的元素（如
.list-item）写will-change: transform - 示例：
.card.is-animating { will-change: transform; }
JS 中：el.addEventListener('touchstart', () => el.classList.add('is-animating'))
动画一结束，立刻移除 will-change
动画播放完毕后若不清理，图层不会自动释放，持续消耗资源。必须监听 animationend 或 transitionend 事件来清除。
- 推荐搭配 CSS 的
animation-fill-mode: forwards，确保样式保持，再由 JS 移除 class - 也可直接操作内联样式：
el.style.willChange = 'auto' - 注意：不要依赖
setTimeout延迟移除，时间难对齐；优先用原生事件
仅配合 transform 和 opacity 使用
will-change 对 left、top、width、background-color 等属性无效——这些属性本身就会强制触发布局或重绘，升层也救不了。只有 transform 和 opacity 能走纯合成线程，will-change 才有发挥空间。
- 位移动画统一改用
transform: translateX()，别用left - 缩放/旋转用
scale()、rotate()，而非改width或height - 透明度用
opacity，不用rgba()改 alpha（后者仍属重绘）
用 DevTools 验证是否真实生效
别凭感觉判断是否优化成功。打开 Chrome DevTools → Layers 面板，触发动画，观察目标元素是否生成了独立图层（Layer）。若没出现，说明 will-change 未被浏览器采纳，需检查属性是否合法、是否被覆盖、或是否处于不可见/未渲染状态。
- 可同时开启 Rendering 面板中的 “Paint flashing” 和 “Layer borders”，直观查看重绘区域与图层边界
- 注意：某些旧版 Safari 不支持
will-change，可兜底加transform: translateZ(0)，但现代项目中应以will-change为主
