will-change不是gpu缓存开关，而是提示浏览器预升层、预分配纹理内存的信号；是否升层及何时生效由浏览器策略决定，无法强制或观测。
直接说结论： will-change 不是“通知 GPU 预留缓存”的开关，它只是给浏览器一个**提示信号**，告诉渲染引擎：“接下来这个元素的某些属性大概率会变，请提前升层、预分配纹理内存”。但是否真升层、何时升层、升几层，完全由浏览器内部策略决定——你无法强制、也无法观测其生效状态。
为什么 will-change: transform 有时没效果？
常见现象：加了 will-change: transform，动画依然卡顿，DevTools 的 Layers 面板里也看不到新合成层。
- 浏览器会忽略重复或过早设置的
will-change（比如在元素初始化时就写死在 CSS 里） - 元素本身不满足升层条件：例如没有
transform、opacity等可被硬件加速的属性变化，或父级有overflow: hidden拦截了层叠上下文 - 元素尺寸为 0 或不可见（
display: none/visibility: hidden），Chrome 会直接跳过层合成 - 部分 Android WebView 或旧版 Safari 对
will-change支持不完整，甚至完全忽略
JS 中动态设置 will-change 的正确时机
必须和动画触发强绑定，不能“提前太久”，也不能“太晚”——理想窗口是：用户交互触发后、requestAnimationFrame 第一帧绘制前。
- 在
mousedown/touchstart时设置：el.style.willChange = 'transform' - 在
requestAnimationFrame回调中立即开始动画（比如el.style.transform = 'translateX(100px)'） - 动画结束后（如 transitionend 或 rAF 循环结束），**必须清除**：
el.style.willChange = 'auto'；否则长期占用 GPU 内存，反而引发掉帧 - 避免对大量元素批量设置；优先只作用于当前正在交互动画的那 1–2 个元素
will-change 和 transform: translateZ(0) 的区别
两者都可能触发合成层，但机制完全不同：
-
transform: translateZ(0)是**强制升层**的 hack，不管需不需要，都会创建新层，容易导致层爆炸（layer explosion），尤其在滚动容器里滥用会显著增加内存与合成开销 -
will-change是**提示式升层**，更轻量，但依赖浏览器判断；它不会改变布局、不影响盒模型，只影响渲染流水线决策 - 现代 Chrome 中，
will-change: transform在多数场景下比translateZ(0)更安全；但若目标属性不是transform或opacity（比如left/top），will-change基本无效
真正关键的不是加不加 will-change，而是确保动画属性可被硬件加速（只用 transform 和 opacity）、避免 layout thrashing、控制合成层数量。很多卡顿问题，其实清掉 will-change 反而更稳——因为它掩盖了底层 DOM 更新或重排的真实瓶颈。
