will-change 不是用来“优化重绘”的，它只对后续将变更的 transform 或 opacity 起提示作用；加了它但没动这两个属性，或者用在 background-color、width 上，等于白写，还可能拖慢首屏。
直接说结论：will-change 不是用来“优化重绘”的，它只对后续将变更的 transform 或 opacity 起提示作用；加了它但没动这两个属性，或者用在 background-color、width 上，等于白写，还可能拖慢首屏。
will-change 写在 HTML 标签里完全无效
所有类似 will-change="transform"、will-change_html 的写法，浏览器当普通自定义属性处理，不解析、不报错、不触发任何优化。它不是 HTML 属性，只接受 CSS 声明：
<div style="will-change: transform"> —— 有效，但需配合 JS 动态控制 <li> <code>.anim-item { will-change: transform; }—— 合法，但静态写死极易导致图层泛滥<div will-change="transform"> —— 完全无效，别浪费时间调试 <h3>哪些值真能触发图层提升，哪些是白忙活</h3> <p><code>will-change只对浏览器认定为“可合成”的属性起作用，且必须后续真有变更。常见情况如下：-
transform：最稳妥，Chrome 36+ / Firefox 36+ 全支持，配合translate3d(0,0,0)或动画使用才生效 -
opacity：必须是明显变化（如0 → 1），0.99 → 1这类微调通常被忽略 -
scroll-position：仅对滚动容器有效，但现代 Chrome/Firefox 处理保守，常降级为无操作 -
left、top、width、background-color：加了也白加，这些属性本身触发重排/重绘，will-change对它们不起作用 -
will-change: all：浏览器直接忽略，语义失控，绝对禁止
动态控制生命周期比静态声明安全十倍
写死在 CSS 里（比如
.list-item { will-change: transform; }）会让每个匹配元素长期占 GPU 图层，100 个列表项 = 100 个图层，显存飙升、滚动卡顿立马出现：- 动画开始前 1–2 帧设：
el.style.willChange = 'transform, opacity' - 监听
transitionend或animationend，结束后立刻设回'auto'或清空该 style - 避免只在
mouseenter加，却忘了在mouseleave移除——图层不会自动回收 - 对长列表，优先只对
window.getIntersectionObserver检测到的可视区域元素启用
验证是否真生效，别靠猜
加了
will-change不代表优化成功，必须实测确认：- 打开 Chrome DevTools → More Tools → Layers 面板，手动触发动画或滚动
- 看到目标元素出现在图层列表中，且 Reason 字段显示
layer-for-transform或layer-for-opacity，才算真正升层 - 如果 Reason 是
will-change，仅代表提示收到，不代表已执行优化 - 勾选 Rendering 面板中的 «Paint flashing»：满屏绿色闪动，基本就是
will-change泛滥了
真正难的不是怎么加
will-change，而是判断「这个元素是否真需要独立图层」——它不解决 layout/reflow 问题，只在合成路径上帮浏览器省一步；约早了浪费，约错了失效，约多了拖垮整页。-
