will-change 会立即创建 GPU 合成层，不是“等动画开始再建”；只要声明即分配显存，与是否真实动画无关，静态滥用会导致显存暴涨甚至 OOM。
will-change 会立即创建 GPU 合成层，不是“等动画开始再建”
很多人以为 will-change 是个懒加载开关：动画一动它才生效。实际完全相反——只要样式匹配或 JS 设置了该值，浏览器立刻为元素分配独立 GPU 纹理，显存占用当场发生，和是否真在动无关。
典型错误是写死在 CSS 里：.list-item { will-change: transform; }。一屏渲染 20 个卡片，就等于强制申请 20 块 GPU 纹理；若卡片尺寸是 375×240px、DPR=3，单个纹理就要 ≈3.24MB，20 个就是 ≈65MB 显存——这还没算投影、伪元素撑大的包围盒。
- Android 中低端机 GPU 共享内存通常仅 128–256MB，几个列表页叠加就触发 Jetsam OOM
- iOS Safari 对图层数更敏感，常驻图层超 10 个就可能白屏或强制 reload
- Chrome DevTools 的 Layers 面板能直接看到“Compositing layers”数量和每层 KB 占用，比看 JS Heap 更准
只对 transform / opacity 有效，其他属性加了也白占资源
will-change 不是通用加速器，它只对后续真正由 transform 或 opacity 驱动的动画起作用。浏览器识别到不支持合成的属性（比如 left、width、background-color），会忽略提示，但图层仍被错误创建——纯属浪费。
-
will-change: left→ 浏览器无视，但依然升层，显存照吃 -
will-change: box-shadow→ 触发重绘，无法合成，毫无收益 -
will-change: contents→ 强制整个子树升层，1 行文字可能拉出 15+ 图层，高危
验证方法很简单：打开 Chrome DevTools → Cmd+Shift+P 输入 “Rendering” → 勾选 Layer borders。没橙色边框？说明根本没升层，will-change 白写了。
静态声明 = 内存泄漏，JS 动态控制才是唯一安全路径
写在 CSS 文件里的 will-change 是常驻状态，元素挂载即升层，卸载也不自动释放（尤其 Android WebView）。真正可控的方式，是用 JS 在动画前一刻设置、结束后立刻清空：
- 设置时机：在
touchstart、click或mouseenter后、动画 class 添加前那一帧（推荐用requestAnimationFrame包一层） - 清除时机：监听
animationend（不是transitionend），并设为'auto'；iOS Safari 有时不触发，建议加setTimeout(() => el.style.willChange = 'auto', 350)兜底 - 千万别写
el.style.willChange = ''—— 空字符串无效，必须是'auto'
滚动容器加 will-change: transform 是常见误用点
给 .scroll-container { will-change: transform; } 看似能“优化滚动”，实则是靠骗浏览器提前升层来绕过主线程重绘。但它有严格前提：
- 只能加在滚动容器本身（如
div.overflow-y-scroll），绝不能加在内部每个.item上 - 若容器已有
transform或opacity动画，浏览器通常已自动提层，再加反而冗余 - 父级若设了
overflow: hidden或contain: paint，会抑制提层，will-change直接失效
最易被忽略的事实：will-change 不是渲染加速器，它是 GPU 显存的预约指令——预约早了浪费，预约错了失效，预约多了拖垮整页。它解决不了 layout 或 paint 阶段的性能瓶颈，只服务于已经迁移到合成线程的 transform/opacity 动画。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
