will-change 不是性能开关，而是向浏览器提前声明需创建独立合成层的指令；静态滥用会导致显存暴涨、卡顿甚至OOM崩溃，仅动态控制transform/opacity动画且帧率不足55fps时才应谨慎使用。
will-change不是性能开关，加了不会自动变快；它是向浏览器“提前下单”GPU图层的指令——每声明一次，浏览器就真建一块独立合成层，占几MB显存。静态写死、批量加、加在错误属性上，轻则卡顿，重则在 Android 4.4–6.0 WebView 或 iOS Safari 中直接 OOM 崩溃。
哪些 CSS 属性加 will-change 完全无效
浏览器只对能走纯合成路径的属性响应 will-change，其余全是白占资源：
-
will-change: left、will-change: top、will-change: width、will-change: height：触发布局（reflow），浏览器忽略或照建图层但动画仍走 CPU 渲染 -
will-change: background-color、will-change: box-shadow：触发重绘（paint），无法合成，will-change不提升帧率，只增内存开销 -
will-change: contents：高危操作，会让整个子树升层，10 行文本可能拉出 20+ 图层，严禁用于容器类元素 -
will-change: position：CSSposition本身不是可动画属性，浏览器不识别，也不生效
移动端加 will-change: transform 反而更卡的常见原因
原生滚动容器、列表项、错设父级，都会让 will-change 从优化变成负优化：
- 给
overflow-y: auto的滚动容器加will-change: transform：干扰浏览器内置滚动合成策略，DevTools Layers 面板图层数 > 8 就大概率掉帧 - 静态写
.list-item { will-change: transform; }：一屏 20 个，等于常驻 20 个图层，中低端安卓机纹理上传阻塞，帧率跌破 20fps - 父容器设了
will-change，但位移的是子元素：信号发错对象，图层建得过大、空转耗资源 - 带
border-radius+overflow: hidden的容器：强制回退软件渲染，will-change彻底失效 - 初始为
display: none或visibility: hidden的元素：will-change根本不生效
真正安全的用法只有 JS 动态控制 + 严格生命周期
静态规则里写 will-change 基本等于埋雷。唯一可靠路径是交互前加、动画后删，且清理时机必须精确：
- 加：在
touchstart、mouseenter或animationstart中执行element.style.willChange = 'transform' - 删：必须用双
requestAnimationFrame，确保绘制完成后再释放：requestAnimationFrame(() => { requestAnimationFrame(() => { element.style.willChange = 'auto'; }); }); - 监听事件要匹配动画类型：
@keyframes动画监听animationend，不是transitionend；过渡动画才用transitionend，且加{ once: true }防重复绑定 - Chrome 98+ 已默认对
transform和opacity动画自动升层，静态声明基本失效，还白占资源
验证你是否已滥用 will-change 的三个硬指标
别信“感觉流畅”，只看 DevTools 里的真实数据：
- 打开 Chrome DevTools → More Tools → Layers，筛选内存 > 2MB 的图层，点开看归属元素是不是批量渲染的
.item或弹窗容器 - Rendering → «Paint flashing»，滚动时满屏绿色闪动，说明重绘失控，
will-change没起作用反而加重负担 - Performance 面板录制滚动过程，GPU Memory 曲线持续爬升而非稳定波动，就是图层没回收的铁证
最易被忽略的一点：will-change 本身不节省 CPU 时间，它只换来 GPU 内存开销——只有当你已确认某元素在做纯 transform/opacity 动画、且实测帧率低于 55fps 时，才值得引入，并必须配 JS 动态管控整个生命周期。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
