will-change 触发的是合成层预分配优化，即在样式计算阶段提前创建独立GPU合成层、预分配内存并缓存纹理，从而跳过动画开始时临时升层的开销。
will-change 本身不提升性能，它只是让浏览器提前分配 GPU 合成层、跳过初始帧的布局/绘制准备，从而避免动画第一帧卡顿。真正起作用的是 transform 和 opacity 这类只触发合成的属性，而 will-change 只是给它们“抢跑”1–2 帧的机会。
will-change 触发的是哪一步渲染优化？
浏览器渲染流程分四步：样式计算 → 布局（Layout）→ 绘制（Paint）→ 合成（Composite）。其中 Layout 和 Paint 最耗时，而 Composite 可由 GPU 加速。will-change 不改变这四步顺序，只让浏览器在「样式计算」阶段就决定：这个元素接下来大概率要进独立合成层，现在就开层、预分配 GPU 内存、缓存纹理。
这意味着当 transition 或 animation 真正开始时，浏览器跳过了临时升层的开销——实测中，未加 will-change 的卡片 hover 动画首帧延迟常达 25–40ms；加了且时机得当，可压到 5ms 以内。
-
will-change: transform会促使浏览器提前创建一个仅含变换信息的合成层，后续transform变化只走 Composite 阶段 -
will-change: opacity同理，但若同时改background-color，该层仍会因 Paint 触发而降级 -
will-change: left无效：它强制 Layout，浏览器无法跳过，还会多一层无用图层 -
will-change: all被现代浏览器忽略，等于没写
哪些值真正触发硬件加速？
只有少数 CSS 属性变更能完全绕过 Layout 和 Paint，仅依赖 Composite。will-change 对它们才有效：
立即学习“前端免费学习笔记（深入）”；
-
transform（包括translate、scale、rotate、skew）——安全高效 -
opacity—— 安全高效 -
filter（部分函数，如blur()、grayscale()）—— 有兼容性风险，iOS Safari 易卡顿 -
scroll-position—— 仅对可滚动容器生效，用于平滑滚动优化 -
contents—— 仅适用于频繁 DOM 更新的区域（如实时聊天消息流），但需配合contain: paint
以下值基本无效，加了反而可能引发回流或重绘：left、top、width、height、margin、padding、background-color。
为什么不能一开始就写在 CSS 里？
因为 will-change 是资源预约指令，不是开关。写死在样式表中，等于让浏览器永远为这个元素保留一块 GPU 内存——哪怕它 90% 时间静止不动。
常见错误现象：.card { will-change: transform; } 导致整页首屏加载慢 30ms，长列表滚动卡顿，iOS Safari 白屏概率上升。
- 正确做法：用 JS 在交互触发前 1–2 帧动态添加，例如
el.addEventListener('mouseenter', () => el.style.willChange = 'transform') - 必须配套移除：监听
transitionend或animationend，执行el.style.willChange = 'auto'（比removeProperty更可靠） - 避免父容器滥用：子元素已用
transform动画，父元素再加will-change只会多一层空图层 - 移动端尤其谨慎：iOS Safari 图层管理更激进，大量 will-change 容易触发内存回收失败
替代方案有时更稳
多数场景下，transform: translateZ(0) 或 transform: translate3d(0, 0, 0) 就够用了——它隐式触发图层提升，无需 JS 控制生命周期，也没有移除遗漏风险。
只有当你需要精细控制图层创建时机（比如复杂交互动画链、滚动锚点联动、Canvas 与 DOM 混合渲染）时，才值得引入 will-change 并手动管理。
最容易被忽略的点是：它约早了浪费，约错了失效，约多了拖垮整页。别把它当“动画加速器”贴满页面。
