will-change 不是“加了就快”的开关，而是高风险资源预约指令；仅 transform、opacity、filter、backdrop-filter 有效，滥用反而更卡，须动态设置并及时清除，且优先解决主线程阻塞与布局重算问题。
will-change 不是“加了就快”的开关，而是高风险资源预约指令；滥用它比不用更卡，尤其在移动端。
哪些值真正触发 GPU 加速
浏览器只对极少数 CSS 属性响应 will-change 并创建合成层：只有 transform、opacity、filter 和 backdrop-filter 有效。其他写法基本白忙活：
-
will-change: left或will-change: top→ 强制触发布局（reflow），浏览器直接忽略或回退到软件渲染 -
will-change: width、will-change: height、will-change: background-color→ 不生成图层，还可能干扰后续真实动画的分层时机 -
will-change: all→ 现代浏览器（Chrome 90+、Safari 15.4+）会直接无视，等于放弃控制 -
will-change: scroll-position→ 多数浏览器不支持，iOS Safari 完全无效，别填
怎么加才不翻车：动态控制生命周期
静态写在 CSS 文件里（比如 .item { will-change: transform; }）是最常见翻车点——所有匹配元素永久占着 GPU 内存，图层不释放，滚动直接掉帧。
- 必须用 JS 在动画开始前 1–2 帧动态设置：
element.style.willChange = 'transform'; - 必须在动画结束后立刻清除：
element.addEventListener('animationend', () => { element.style.willChange = 'auto'; }); - 推荐嵌套两层
requestAnimationFrame清除，确保绘制完成后再销毁图层，避免闪屏 - 不要对父容器和子元素同时设 —— 比如
.list-container和里面的.item都加will-change: transform，图层嵌套放大开销
移动端长列表滚动场景下的典型误用
给每个列表项（.item）加 will-change: transform 是最典型的性能灾难。一屏显示 10 个，滚动中常驻 20+ 个，等于塞给 GPU 20 多个独立图层。
- 中低端 Android 设备（Chrome 85–95）极易触发纹理上传阻塞，帧率跌破 20fps
- 真正该设的地方只有一个：
.list-container或.scroll-content这类承载位移的滚动容器 - 且必须配合真实
transform变化（如transform: translateY()或transform: translateZ(0)），否则提示无效 - 用 Chrome DevTools 的 Layers 面板确认图层数：稳定在 3～5 层为佳，超过 8 层就要立刻排查
比 will-change 更关键的三件事
90% 的移动端卡顿根源不在渲染层没加速，而在主线程被拖住或布局反复重算。加 will-change 前请先确认：
- 滚动监听是否用了
{ passive: true }？iOS Safari 不加这个，惯性滚动可能被禁用 - scroll 回调里有没有读取
scrollTop或调用getBoundingClientRect()？这会强制同步回流（layout thrashing） - 列表项里的图片是否设了宽高 +
loading="lazy"？没设就会每张图加载都触发重排
真正容易被忽略的是：will-change 不解决主线程阻塞，也不修复布局抖动。它只在你已经用对 transform 和 opacity、且观察到掉帧时，才值得作为最后一道精细调控手段介入。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
