will-change 强制创建合成层导致内存泄漏，仅 transform/opacity 动画有效，须用 JS 动态控制“添加-清除”生命周期，静态声明等于主动制造内存泄漏。
will-change 一加就卡，是因为它强制建图层而非“建议”
浏览器看到 will-change: transform 不会犹豫或判断，而是立刻为该元素分配 GPU 纹理内存、创建独立合成层（composited layer）。这个过程不依赖是否真有动画，也不随鼠标移开或滚动停止自动释放。Android 4.4–6.0 WebView 完全不回收闲置图层，iOS Safari 对常驻图层极度敏感——哪怕只动一帧，图层也常驻内存直到页面卸载。
DevTools 的 Layers 面板里能看到图层数量持续上涨，Performance 面板中 GPU Memory 曲线呈直线上升，而非稳定波动。20–30 个列表项同时匹配 .item { will-change: transform; }，低端安卓机 10 秒内就可能 OOM 崩溃。
哪些写法等于主动制造内存泄漏
静态写死在 CSS 文件里的 will-change 是最危险的用法，它让所有匹配元素在 DOM 挂载时就升层，与是否真要动画完全无关：
-
.list-item { will-change: transform; }→ 一屏 50 条 = 50 个常驻图层 -
div:hover { will-change: transform; }→ hover 时才加，但离开后不清理，图层堆积 -
* { will-change: transform; }→ 全局污染，连<span>都被拉进 GPU 图层 -
will-change: left或will-change: width→ 这些属性无法合成，浏览器忽略提示，但图层仍被错误创建 -
will-change: contents→ 强制整个子树升层，10 行文本可能生成 20+ 图层
只有 transform/opacity 动画才值得加 will-change
will-change 只对能走合成路径的属性起作用。浏览器渲染管线中，只有 transform 和 opacity 能绕过 Layout 和 Paint 阶段，交由合成器线程独立处理。其他任何属性加了都救不回来：
立即学习“前端免费学习笔记（深入）”；
- 用
left/top做位移动画？加了will-change: transform也无效——浏览器仍要反复计算布局（reflow） - 用
rgba()改 alpha？不如直接用opacity，后者才是合成友好型 - 给
overflow: scroll容器加will-change: scroll-position有效，但给position: fixed弹窗加就完全无效，还白占资源
真正卡顿时，先打开 Chrome DevTools → Performance 录制动画：如果主线程卡在 Paint 或 Layout，说明问题不在合成层，will-change 加了也没用；只有 Composite 占比高且帧率低于 60fps 时，才考虑介入。
动态控制生命周期是唯一安全路径
静态声明等于默认开启“内存泄漏模式”。必须靠 JS 精确控制“申请-释放”节奏：
- 添加时机：仅在
touchstart、mouseenter或animationstart中执行el.style.willChange = 'transform' - 清除时机：必须用双
requestAnimationFrame，确保图层已稳定绘制：requestAnimationFrame(() => { requestAnimationFrame(() => { el.style.willChange = 'auto'; }); }); - 监听
animationend（不是transitionend），并加setTimeout兜底（iOS Safari 对短于 16ms 的动画可能不触发该事件） - 父容器不能有
overflow: hidden、filter或非 identity 的transform，否则子元素升层失败
最容易被忽略的一点：will-change 本身不节省 CPU 时间，它只换来了 GPU 内存开销。只有当你已确认某元素在做纯 transform/opacity 动画、且帧率实测低于 55fps 时，才值得引入——并且必须配 JS 动态控制生命周期。
