will-change 不是性能开关而是内存预订单，静态声明等于批量申请 GPU 显存且不自动回收，易致 OOM；安全用法仅限交互前动态添加、动画后双 requestAnimationFrame 清除。
will-change 不是性能开关，是内存预订单——写死在 CSS 里等于批量申请 GPU 显存，不清理就 OOM。
为什么一加 will-change 就卡甚至崩溃
浏览器看到 will-change: transform，真会立刻分配一块 GPU 内存建合成层；Android 4.4–6.0 WebView 和 iOS Safari 都不自动回收闲置图层。50 个元素同时声明，等于硬塞 50 块显存，滚动几秒后 GPU Memory 曲线直线上升，最终触发 Out of Memory 崩溃。
常见错误现象包括：DevTools Layers 面板里图层数量居高不下、文字模糊（图层缩放失真）、动画首帧严重掉帧、切换路由后图层不回落。
-
will-change: left、will-change: width这类无效声明，浏览器虽不升层，但照样解析匹配、占用样式系统资源 -
will-change: contents是高危写法，10 行文本可能拉出 20+ 图层 - Vue/React 列表项用
v-for或.map()渲染时，对每个.item都加will-change: transform类——动画一开，上百图层齐飞
怎么动态加、必须怎么删
静态写死在 CSS 规则里（如 .list-item { will-change: transform; }）等于主动制造内存泄漏。真正安全的用法只有一种：交互前加，动画后删，且不能立刻删。
立即学习“前端免费学习笔记（深入）”；
- 加：在
touchstart、mouseenter或animationstart中执行element.style.willChange = 'transform' - 删：必须用双
requestAnimationFrame，确保图层已稳定绘制再释放：requestAnimationFrame(() => { requestAnimationFrame(() => { element.style.willChange = 'auto'; }); }); - 别用
setTimeout或单层requestAnimationFrame清理——前者延迟不可控，后者易导致闪屏或掉帧 - 监听
transitionend时加{ once: true }，防止重复绑定；@keyframes动画要监听animationend，而非transitionend
哪些场景根本不需要 will-change
Chrome 98+、Edge、Safari 已默认对 transform 和 opacity 动画自动升层，静态声明基本失效，还白占资源。
- 滚动容器上写
will-change: transform—— 滚动本身不是 transform 变化，纯属误导浏览器 - 混用
transition: all或含background-color的动画链 —— 只要任一属性触发布局重排，整个动画退化为 CPU 渲染，will-change彻底无效 - 用
getBoundingClientRect()或同步改写style触发强制回流 —— 主线程已阻塞，图层优化毫无意义 - 图片缺失宽高、未用
loading="lazy"导致布局抖动 —— 卡顿根源在此，不是图层不够
比 will-change 更稳妥的替代方案
多数情况下，硬触发合成层比依赖提示更可控：
- 轮播容器、弹窗遮罩等长期动效区域，直接用
transform: translateZ(0)或transform: translate3d(0, 0, 0)，语义明确、兼容性好 - 滚动优化优先用
contain: paint或overscroll-behavior: contain，而非will-change: scroll-position - 动画只用
transform和opacity，避开height、margin、background-color—— 这些本身就会触发重排/重绘，加了will-change也救不回来
真正要盯住的不是要不要加 will-change，而是图层生命周期：它什么时候建、什么时候毁、有没有残留。打开 DevTools → More Tools → Rendering → Layer borders，滑动、触发动画，绿色框密集嵌套就是危险信号。
