will-change是css属性，非html属性，必须通过style或css规则设置；仅对transform、opacity等特定值生效，滥用反致性能下降。
will-change 不是 HTML 属性，不能写在 HTML 标签里——任何类似 will-change_html、will-change 作为 HTML 属性的写法都完全无效，浏览器直接忽略。
为什么 will-change 必须用 CSS 设置
它是一个纯 CSS 渲染提示属性，作用于「分层（layerization）」阶段，只在浏览器构建渲染树时起效。HTML 解析器根本不认识它，所以：
❌ <div will-change="transform"> —— 自定义属性，无意义<br>✅ <code><div style="will-change: transform"> —— 有效，但需谨慎<br>✅ <code>.target { will-change: transform; } —— 合法，但有长期驻留图层风险
will-change 只对特定 CSS 属性生效
浏览器只响应有限几个值，其他一律忽略或降级处理：
-
transform：最常用、兼容性最好（Chrome 36+、Firefox 36+） -
opacity：必须是明显变化（如0 → 1），0.99 → 1这类微调不触发合成 -
scroll-position：仅对滚动容器有效，且现代 Chrome/Firefox 处理保守，常被跳过 -
content-visibility：部分浏览器支持，但语义与优化目标不同，慎用 -
left、top、width、background-color等：加了也白加，触发重排/重绘，will-change对它们不起作用
动态控制比静态声明更安全
写死在 CSS 里（比如全局 .item { will-change: transform; }）等于让几百个元素长期占着 GPU 图层，显存飙升、内存泄漏风险高。真实场景应配合 JS 动态开关：
- 在动画开始前 1–2 帧设
el.style.willChange = 'transform, opacity' - 监听
animationend或transitionend，结束后立刻设回'auto' - 避免在
mouseenter里加、却忘了在mouseleave移除——图层不会自动回收 - 对列表项批量操作时，宁可只对当前可视区域内的元素启用
验证是否真生效，别靠猜
打开 Chrome DevTools → More Tools → Layers 面板，手动触发动画或滚动：
- 看到目标元素出现在图层列表中，且
Reason字段写着layer-for-transform或layer-for-opacity，才算成功升层 - 如果
Reason是will-change，仅代表浏览器收到了提示，不代表已执行优化 - 勾选 Rendering 面板里的 «Paint flashing»：满屏绿色闪动，基本就是
will-change泛滥了 - 真正提速的前提是后续确实变更了
transform或opacity；只设will-change不动属性，毫无意义
最容易被忽略的一点：will-change 不是“开箱即用的加速器”，而是“高代价的预分配指令”。它本身不节省 CPU 时间，反而增加 GPU 内存开销——只有当你已经确认某处动画卡顿、且排除了 layout / paint 问题后，才值得介入。
