will-change 不该静态写在 transition 的 css 中，因现代浏览器已自动为 transform/opacity 创建合成层，冗余声明会浪费显存、引发掉帧；仅当动画已用 transform/opacity 且 performance 面板显示 composite 滞后时，才用 js 动态、短暂启用。
绝大多数情况下，will-change 不该出现在 transition 的 CSS 声明里——加了不仅没用，还可能让动画更卡。
为什么静态写 will-change: transform 对 transition 无效
Chrome 98+、Safari 16.4+、Edge 114+ 已默认为 transform 和 opacity 的 transition 创建独立合成层。你再在 CSS 里写 will-change: transform，等于强行让元素“常驻图层”，长期占用 GPU 内存。
- 一屏有 20 个卡片，每个都带这个声明 → 至少多占 10MB 显存，低端 Android 设备滚动直接掉帧
- DevTools 的 Layers 面板里能看到：如果 transition 已稳定跑在合成层上，
will-change就是冗余操作 - 所谓“加了变流畅”，大概率是偶然触发了某次未预期的分层策略，不是真实优化
真正卡顿时，先检查 transition 本身是否写错
加 will-change 解决不了错误的动画写法；它只对已走合成路径的动画起微调作用。卡顿根源往往在属性选择上：
-
left、top、width、height、background-color等属性触发布局或重绘 → 加will-change完全无效，甚至干扰浏览器原本的优化节奏 - 位移必须用
transform: translateX()，缩放必须用scale()，透明度必须用opacity - 用 Chrome DevTools → Performance 面板录制动画：若主线程 Layout/Paint 占满，说明问题在代码；只有 Composite 阶段滞后，才考虑
will-change
真要动态加，必须 JS 控制生命周期
仅当明确观测到首帧卡顿（Performance 面板出现长绘制帧）、且动画已迁移到 transform 或 opacity 上时，才临时启用。关键不是“加”，而是“什么时候加、什么时候撤”：
- 触发前：用双
requestAnimationFrame设置element.style.willChange = 'transform'—— 第一帧通知浏览器准备，第二帧才真正触发动画，留出分层时间 - 清理必须设为
'auto'，不是空字符串或''；后者不生效，图层不会释放 - 监听
transitionend，但 iOS Safari 常丢事件，得加setTimeout兜底（如 600ms 后强制设'auto'） - 避免给子项批量加：轮播图、模态框等结构，只升容器；几十个商品卡片全加，等于造几十个图层，每个约占 0.5MB 显存
真正难的不是加 will-change，而是判断它该不该加、加在哪一层、加多久——它不是性能开关，是手术刀；下错一刀，比不加更糟。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
