will-change 对高频动画无效甚至有害，仅对 transform/opacity 有效；Chrome 98+ 后静态声明基本失效，应动态设置并用双 requestAnimationFrame 清除，避免内存泄漏与闪屏。
will-change 对高频动画没用，甚至会让它更卡——除非你只动 transform 或 opacity，且已确认掉帧。
will-change 只对 transform/opacity 有效，其他属性加了白费
浏览器只对 transform 和 opacity 的变化做合成层优化；加 will-change: left 或 will-change: width 不仅无效，还会强制创建图层，触发布局重算，动画反而更卡。常见错误是给 position: static 元素加 will-change: top，浏览器根本无法硬件加速，还多一层无效提示。
- ✅ 有效：
will-change: transform、will-change: opacity、will-change: scroll-position - ❌ 无效甚至有害：
will-change: left、will-change: width、will-change: background-color - ⚠️ 注意：
will-change: contents会阻止子元素继承优化，慎用
Chrome 98+ 后，静态声明 will-change 基本失效
现代 Chrome（98+）、Edge、Safari 已默认对 transform 和 opacity 动画自动创建合成层，你在 CSS 里写 will-change: transform 不会带来额外收益，反而让所有匹配元素长期驻留图层，内存持续上涨。
- 静态写法（不推荐）：
.anim { will-change: transform; } - 动态写法（仅必要时）：
element.style.willChange = 'transform'; - 必须配对清除，否则图层不释放，滚动变慢、内存泄漏风险上升
动态设置 + 双 requestAnimationFrame 清除才是安全写法
动画开始前设 will-change，结束后必须清理；但不能立刻清，否则图层销毁太早，导致闪屏。要用两层 requestAnimationFrame 确保绘制完成后再移除。
立即学习“前端免费学习笔记（深入）”；
element.style.willChange = 'transform';
// 动画结束时
requestAnimationFrame(() => {
requestAnimationFrame(() => {
element.style.willChange = 'auto';
});
});
- 第一层：进下一渲染帧
- 第二层：确保该帧已完成绘制，图层稳定存在过
- 不这么做，
will-change就等于白加，还可能引发视觉撕裂
真正卡顿时，先看 Performance 面板再决定要不要加
打开 Chrome DevTools → Performance → 录制一段动画，重点看主线程是否频繁卡在 Paint 或 Layout 阶段。如果只有 Composite 占比高、帧率低于 60fps，且动画只用 transform/opacity，才考虑加 will-change。
- ✅ 加的信号：主线程空闲，但合成阶段延迟高，首帧明显滞后
- ❌ 别加的信号：主线程满载、大量
Layout或Paint，说明该优化 JS 或 CSS 结构，不是will-change能解决的 - 替代方案优先级更高：
contain: strict、减少 DOM 深度、用scroll-driven animations替代 JS 滚动监听
真正容易被忽略的是：will-change 不是性能开关，它是浏览器渲染流水线里的一个“预约通知”。通知错了时间、通知了错误的人、通知完不取消——都会让系统更忙，而不是更顺。
