will-change 对 left/top 无效且拖慢性能，仅对 transform、opacity、filter、backdrop-filter 有效；定位动画必须改用 transform: translateX/Y 才能 GPU 合成，避免混用 left 与 transform，并动态精准控制 will-change 生命周期。
will-change 对 left/top 定位动画完全无效，加了反而触发重排、拖慢性能。 它只对 transform、opacity、filter、backdrop-filter 四个属性起作用；用在定位动画上等于主动告诉浏览器“请立刻开始反复计算布局”，卡顿是必然结果。
为什么 will-change: left 或 will-change: top 没用还更卡
浏览器无法对 left、top 这类布局属性做合成层优化 —— 它们一变就得重新计算整个文档流（reflow），will-change 根本插不上手：
-
will-change: left被 Chrome 和 Safari 直接忽略，或回退到软件渲染 - 元素仍走主线程 Layout → Paint → Composite 流程，帧率直线下跌
- 若同时设了
position: relative+left，还会干扰后续真正能合成的transform动画分层时机
想让定位动画流畅，必须迁移到 transform
真正能走 GPU 合成线程的位移，只有 transform: translateX()、translateY() 这类。这不是“锦上添花”，而是硬性前提：
- 把
left: 100px改成transform: translateX(100px) - 避免混用：不要同时写
left和transform，否则浏览器会降级回 Layout - 动画中别读取
offsetLeft或getBoundingClientRect()—— 强制同步 Layout，打断管线
动态加 will-change 的正确时机和写法
仅当动画真由 transform 驱动时，才值得 JS 动态设置，并严格控制生命周期：
立即学习“前端免费学习笔记（深入）”；
- 交互触发瞬间（如
touchstart、mouseenter）设element.style.willChange = 'transform' - 监听
transitionend或animationend，不用setTimeout猜时长 - 清除必须用双
requestAnimationFrame：requestAnimationFrame(() => { requestAnimationFrame(() => { element.style.willChange = 'auto'; }); }); - 别在父容器和子元素同时设 —— 比如
.list和.item都加transform，图层嵌套开销翻倍
真正卡顿时，先打开 Chrome DevTools 的 Layers 面板看图层数量，再看 Performance 面板里 Composite 阶段是否滞后；如果主线程 Layout 占比高，will-change 一个字都别加 —— 那是代码结构问题，不是渲染提示问题。
