will-change 必须加在实际发生变换的元素本身上，而非父容器或触发器；错误添加会导致性能下降、内存浪费，正确做法是动画前动态设置、动画后立即清除，并避免滥用和混用。
will-change 该加在哪个元素上？
加错位置是性能不升反降的主因。它必须作用于「实际发生变换的元素本身」，而不是父容器或动画触发器。
常见错误现象：will-change: transform 加在按钮上，但真正位移的是弹窗 .modal —— 浏览器会为按钮创建合成层，却对 modal 的重绘毫无帮助，还多占内存。
- 正确做法：直接写在动画中属性变化的元素上，比如
.slide-in元素有transform动画，就给它加will-change: transform - 如果动画涉及多个属性（如
transform和opacity），写全：will-change: transform, opacity，别偷懒只写一个 - 避免全局滥用：不要在
* { will-change: transform }这类规则里用，现代浏览器对这种写法会直接忽略或降级处理
什么时候该删掉 will-change？
它不是“设了就完事”的开关，而是临时提示。长期挂着反而拖慢渲染，尤其在移动端。
使用场景：只在动画即将开始前一刻设置，动画结束立即清除。比如用 JS 控制：
element.style.willChange = 'transform';
setTimeout(() => {
element.style.willChange = 'auto';
}, 300);
- CSS 动画中无法自动清理，所以更推荐 JS 动态控制；纯 CSS 动画（
@keyframes）慎用will-change，容易常驻合成层 - 滚动容器（如
.scroll-area）不要加will-change: scroll-position—— Chrome 已废弃该值，Safari 不支持，实际无效 - 动画被频繁触发（如 hover 拖拽）时，加防抖逻辑再设
will-change，否则合成层创建销毁太频繁，GPU 内存抖动明显
will-change 和 transform: translateZ(0) 有什么区别？
两者都可能触发合成层，但机制完全不同：translateZ(0) 是“硬触发”，will-change 是“软提示”。
参数差异和兼容性影响：
-
translateZ(0)在所有支持 3D transform 的浏览器都生效，但会强制创建图层，即使后续没动画，图层也一直存在 -
will-change在 Chrome/Firefox/Edge（Chromium）中效果明确，Safari 对will-change的优化策略较保守，有时完全不提升，甚至略卡 - 不要混用：
will-change: transform+transform: translateZ(0)不会叠加效果，反而增加样式计算负担
为什么加了 will-change 还卡？
大概率是其他瓶颈没解决，will-change 只管合成层调度，不管布局、绘制、JS 执行这些环节。
容易踩的坑：
- 动画元素内部有大量重排（如动态改
innerHTML或读取offsetHeight），will-change完全无能为力 - 使用
left/top动画而非transform—— 这种动画必然触发布局 + 绘制，will-change提示无效 - 设备内存紧张（尤其 iOS Safari），合成层太多会被系统回收，导致闪帧；此时应限制同时活跃的动画元素数量，而不是堆
will-change
复杂点在于：它只是渲染流水线里的一个微调项，不能替代动画结构设计。比如列表滚动中逐条淡入，与其给每项加 will-change，不如用 contain: paint 配合虚拟滚动更治本。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
