will-change必须加在实际发生transform或opacity变化的元素本身，而非父容器或触发器；仅动态添加于交互瞬间（如touchstart），动画结束立即移除，并用devtools验证图层是否生成。
卡顿不是因为没开硬件加速，而是will-change加错了属性、加错了时机、加错了元素——它不接管动画，只提示浏览器提前准备图层；用错反而吃内存、掉帧更狠。
will-change 该加在哪个元素上？
必须加在「实际发生属性变化的元素本身」，不是父容器、不是触发按钮、不是 wrapper。
- 错误示例：
.trigger:hover + .modal动画.modal，却给.trigger加will-change: transform—— 浏览器为按钮升层，对弹窗毫无帮助 - 正确做法：直接写在
.modal上，且仅当它真要执行transform或opacity动画时才生效 - 多个属性同时变？写全：
will-change: transform, opacity，别漏掉任一正在过渡的属性 - 绝对不要写
* { will-change: transform }—— 现代浏览器会忽略或降级处理，还拖慢样式计算
什么时候加、什么时候删？
will-change 是临时剧透，不是常驻许可。挂太久等于让浏览器长期占用 GPU 内存，低端 Android 容易 OOM 或合成器抖动。
- 加的时机：用户交互触发瞬间（如
touchstart、mouseenter、click），或requestAnimationFrame第一帧内 - 删的时机：监听
animationend或transitionend后立刻移除；纯 CSS 动画慎用静态声明，容易图层常驻 - 推荐用 class 控制：
.card.is-animating { will-change: transform; }，JS 负责element.classList.add('is-animating')→ 动画播放 →remove - 滚动中频繁触发动画？加防抖逻辑再设，否则图层创建/销毁太猛，GPU 内存抖动明显
哪些值能用、哪些绝对不能碰？
值选错等于主动触发重排重绘，will-change 不但救不了，还会雪上加霜。
- ✅ 安全值：
transform、opacity、scroll-position（注意：Chrome 已废弃，Safari 不支持，实际无效）、contents - ❌ 危险值：
left、top、width、height—— 强制 layout，完全背离优化目标 - ❌ 魔鬼写法：
will-change: all—— 浏览器无法预判，可能升错层、浪费资源 - ⚠️ 替代方案：旧版 Chrome（≤80）或 WebView 中，
transform: translateZ(0)比will-change更轻量、兼容性更好，但别混用两者
怎么验证它真的起作用了？
Lighthouse 报“未启用硬件加速”不用慌——它只扫静态 CSS，看不到 JS 动态设置的 will-change。真实效果得靠 DevTools 看图层是否生成。
- 打开 Chrome DevTools → Rendering → 勾选 “Layer borders”：动画元素周围出现橙色边框，说明独立合成层已建立
- 同时勾选 “Paint flashing”：若动画区域持续绿色闪烁，说明仍在重绘，
will-change没救——问题出在用了background-color或filter这类绘制属性 - Performance 面板录制动画过程：重点看主线程是否被 JS 占满、是否有
Forced reflow，这些和will-change无关，得另查 - 移动端测试务必真机连 DevTools，模拟器图层行为和真实设备差异很大
最常被忽略的一点：will-change 只管图层调度，不管 JS 执行、图片解码、字体加载、阴影绘制——它只是渲染流水线里一个环节。卡顿时先确认是不是动画本身还在用 left、top，或者有没有在 transition 中同步读取 offsetTop 触发强制 layout。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
