will-change 该加在哪个元素上才有效
加错位置是性能优化失败的最常见原因。will-change 只对**直接受动画影响的属性所在的元素本身**起作用，不是加给父容器就能“惠及子孙”。比如你用 transform 动画一个子元素，却给它的 .container 加 will-change: transform，基本没用——浏览器不会自动把子元素提升为合成层。
实操建议：
- 只加给最终被
transform、opacity或filter修改的元素（例如<div class="slide-item">），而不是它的 <code>list父级 - 避免在
:hover或频繁切换的 class 中动态设置will-change；它本意是“提前告知”，不是运行时开关 - 如果动画由 JS 控制（如
element.style.transform = 'translateX(100px)'），就在 JS 执行前直接设element.style.willChange = 'transform' - 滚动变卡、页面偶发白屏——可能是几十个列表项都加了
will-change: transform - 动画开始前有明显延迟——浏览器正在忙于为所有标记元素分配纹理内存
- 在低配 Android 设备上直接崩溃——GPU 内存耗尽
- 用 Chrome DevTools 的
Layers面板确认是否真有额外合成层被创建，而不是凭感觉加 - 动画结束后立刻清除：
element.style.willChange = 'auto'（注意：不能设为空字符串） - 优先用
transform: translateZ(0)或opacity: 0.99这类轻量 hack 替代，尤其对临时动画 - 仅 CSS 控制的
transition：确保只改transform和opacity，其他属性（如height、left、background-color）会强制触发布局计算 - JS 驱动的动画（如
requestAnimationFrame）：避免在帧内调用offsetWidth等强制同步布局的 API - 复杂 DOM 下的列表滚动动画：考虑用
contain: layout paint限制父容器的影响范围，比全局加will-change更精准 - 同一段代码，在 Chrome 可能流畅，在 Safari 可能内存飙升——尤其在长列表 + 滚动中 hover 触发动画的场景
- Safari 不支持
will-change: scroll-position，但 Chrome 支持，不过目前实用性极低 - 部分安卓 WebView（如 UC 内核）完全忽略
will-change，靠它优化等于白忙 - 不要把它当跨浏览器通用开关，先在目标环境里用
chrome://gpu和 Safari Web Inspector 的Rendering面板验证效果 - 用
@supports (will-change: transform)做特性检测，但别只靠它做降级逻辑——降级应基于性能数据，而非支持与否
will-change 触发后为什么反而卡顿了
因为 will-change 强制创建合成层（compositing layer），而每个合成层都要占用 GPU 内存和管理开销。DOM 越深、节点越多，滥用 will-change 就越容易引发内存暴涨或图层重绘冲突。
常见错误现象：
立即学习“前端免费学习笔记（深入）”；
实操建议：
过渡动画卡顿，但没用 will-change，还能怎么救
很多卡顿根本不是渲染层问题，而是主线程被阻塞。CSS 过渡本身不触发重排（reflow），但如果动画过程中 JS 在疯狂读取 offsetTop、getBoundingClientRect()，或者监听了 scroll 且没节流，照样卡。
使用场景判断：
参数差异提醒：transition: all 0.3s 是隐形陷阱——它会让任何后续 CSS 变更都进过渡队列，包括你没意识到的 box-shadow 或 border 变化。
Chrome 120+ 和 Safari 对 will-change 的处理差异
新版 Chrome 已悄悄降低 will-change 的权重：即使写了，也不一定立即升层，而是结合实际绘制行为动态决定；Safari 则更激进，一旦声明就大概率立刻创建合成层，且不轻易释放。
性能影响很实际：
实操建议：
真正难的不是加不加 will-change，而是得看懂 Rendering 面板里那一堆绿色/黄色/红色的帧时间条，以及哪一帧突然多出了 30ms 的 Composite Layers 开销。
