现代浏览器已自动为transform和opacity的transition创建合成层，静态加will-change不仅无效，还会长期占用GPU内存、拖慢滚动、甚至在低端安卓机上掉帧；仅transform、opacity、filter、backdrop-filter、scroll-position等可合成属性动态设置+双raf清除才可能优化首帧卡顿。
不应该——现代浏览器已自动为 transform 和 opacity 的 transition 创建合成层，静态加 will-change 不仅无效，还会长期占用 GPU 内存、拖慢滚动、甚至在低端安卓机上直接掉帧。
哪些 transition 属性能从 will-change 受益
只有真正走合成路径的属性才可能被 will-change 影响，其他全是白忙活：
-
transform（必须是完整函数，如translateX(10px)，不能只写translate） -
opacity（变化幅度需明显，比如0 → 1，0.99 → 1常被忽略） -
filter和backdrop-filter（部分浏览器支持，需实测） -
scroll-position（仅对滚动容器有效，但 Chrome/Firefox 实际处理保守，慎用）
left、top、width、background-color、color 等加了也无效——它们触发的是 layout 或 paint，will-change 插不上手，反而干扰浏览器原本的优化节奏。
动态设置 + 双 raf 清除才是唯一可行路径
如果你已确认动画卡顿来自首帧（Performance 面板看到长绘制帧），且动画已迁移到 transform 或 opacity，那只能 JS 动态控制生命周期：
立即学习“前端免费学习笔记（深入）”；
- 动画触发前 1–2 帧设：
element.style.willChange = 'transform'; - 监听
transitionend，但 iOS Safari 常丢事件，必须加setTimeout兜底（如 600ms 后强制清理） - 清除必须套两层
requestAnimationFrame：requestAnimationFrame(() => { requestAnimationFrame(() => { element.style.willChange = 'auto'; }); });第一层进下一帧，第二层确保图层已稳定参与合成，否则可能闪屏或撕裂
为什么 CSS 里写 .el { will-change: transform; } 更危险
这种写法等于告诉浏览器“这个元素永远要动”，结果是：
- 一屏 20 个卡片 → 20 个常驻 GPU 图层，每个约占 0.5MB 显存
- 滚动区域（如
.scroll-container）加了会破坏原生滚动优化，强制回退软件渲染 - 元素初始为
display: none或visibility: hidden时，will-change提示仍被预留资源，但根本用不上 - 父容器有
border-radius或overflow: hidden，子元素无法独立图层化，will-change彻底失效
Chrome DevTools 的 Layers 面板里如果看到 Reason 是 will-change，只代表提示收到了，不代表真升层；得看到 layer-for-transform 才算生效。
真正容易被忽略的一点：它不是加速器，而是高代价的预分配指令。你加它的那一刻，GPU 内存就涨了，图层调度开销就加了——没卡顿时加它，就是在给性能埋雷。
