will-change对transition基本无效，仅对transform、opacity等合成属性动态设置才可能优化首帧卡顿；静态声明会浪费GPU资源，错误属性触发还会干扰渲染，需JS精准控制生命周期并配合性能分析工具定位问题。
will-change对transition基本无效，别在CSS里写
静态声明 will-change: transform; 配合 transition 几乎没用。现代浏览器（Chrome 98+、Safari 16.4+）已自动为 transform 和 opacity 的 transition 创建合成层，你再写等于白加，还让所有匹配元素长期占着GPU图层——一屏20个卡片全带这个声明，滚动直接掉帧。
真正要动的，得用JS动态设+双raf清除
只有动画开始前1–2帧设、结束后稳定两帧再清，才可能压掉首帧卡顿。靠CSS class触发 transition 时，必须用JS控制生命周期：
- 触发前：用
requestAnimationFrame设element.style.willChange = 'transform'; - 动画结束监听
transitionend事件，但iOS Safari常丢事件，得加setTimeout兜底（比如600ms后强制设为'auto'） - 清除必须套两层
requestAnimationFrame：requestAnimationFrame(() => { requestAnimationFrame(() => { element.style.willChange = 'auto'; }); });第一层进下一帧，第二层确保图层已稳定参与合成，否则闪屏、撕裂
transition属性选错，will-change完全白费
如果还在用 left、top、width、background-color 做 transition，加 will-change 不仅无效，还会干扰浏览器原本的优化节奏：
-
will-change: left→ 强制触发布局（reflow），浏览器直接忽略或回退到软件渲染 -
will-change: width→ 不生成图层，还可能拖慢后续真实动画的分层时机 - 真正能走合成路径的只有
transform、opacity、filter、backdrop-filter
位移必须用 transform: translateX()，缩放必须用 scale()，透明度必须用 opacity —— 否则升层只是给GPU干等。
立即学习“前端免费学习笔记（深入）”；
别升子项，优先升容器
轮播图、模态框、视差区域这类整体动的结构，只给父容器设 will-change；批量给几十个子项（如商品卡片）都设，等于造几十个独立图层，每个占约0.5MB显存，低端Android设备极易崩溃。
滚动区域（如 .scroll-container）千万别加 translateZ(0) 或 will-change，会破坏浏览器原生滚动优化。文字内容不参与动画时，用 isolation: isolate 隔离，防止被连带升层。
真正卡顿时，先开Chrome DevTools → Performance面板录一段动画，看主线程是否满载（Layout/Paint高）还是Composite阶段滞后——前者调代码，后者才考虑will-change。它不是开关，是手术刀，下刀位置和时机错了，比不用还糟。
