transform 和 opacity 是安全的动画属性，因其不改变文档流和盒模型，可跳过 Layout 和 Paint 阶段，仅由 GPU 在合成层处理；而 width、height、left 等布局属性会触发每帧重排，导致卡顿。
为什么 transform 和 opacity 是安全的动画属性
浏览器对动画的优化集中在「合成层」（compositor layer），只有少数 CSS 属性能被直接交由 GPU 处理而无需触发重排（reflow）或重绘（repaint）。transform 和 opacity 正是其中两个——它们不改变文档流、不影响盒模型，因此动画帧可跳过 Layout 和 Paint 阶段，仅走 Composite。
一旦在 @keyframes 或动画过程中修改 width、height、left、top、margin、padding 等布局相关属性，浏览器就必须每帧重新计算布局，导致主线程阻塞，卡顿立刻出现。
- 错误写法：
@keyframes bad-move { 0% { left: 0; width: 100px; } 100% { left: 200px; width: 200px; } } - 正确写法：
@keyframes good-move { 0% { transform: translateX(0) scaleX(1); } 100% { transform: translateX(200px) scaleX(2); } }
will-change 不是万能解药，用错反而更卡
will-change 的作用是提前告诉浏览器“这个元素接下来要变”，让其提前升层（promote to layer）。但它不能修复本就不该进动画的属性，也不能弥补频繁升降层带来的开销。
常见误用：
立即学习“前端免费学习笔记（深入）”；
- 对所有动效元素统一加
will-change: transform，哪怕只动一次 - 在 hover 中动态设置
will-change，导致反复创建/销毁合成层 - 对父容器设
will-change，却让子元素靠top/left动画——子元素仍会触发 Layout
建议只在明确需要且动画持续时间较长（>1s）时使用，并在动画结束后移除：
element.style.willChange = 'transform'; // 动画结束回调中 element.style.willChange = 'auto';
动画帧率掉到 30fps 甚至更低？先查是否触发了 Layout
Chrome DevTools 的 Rendering 面板勾选 Layout Shift Regions 和 Paint Flashing，再播放动画。如果看到大面积红色闪烁（paint）或黄色高亮（layout），说明正在做昂贵操作。
更准的方法是打开 Performance 面板录制动画过程，关注 Layout 和 Recalculate Style 是否密集出现。若存在，问题一定出在动画属性选择或 JS 干预上。
- JS 中避免读取
offsetLeft、getBoundingClientRect()后立即写style.transform（会强制同步 Layout） - 用
requestAnimationFrame批量读写，或改用IntersectionObserver/ResizeObserver替代轮询 - CSS 中禁用
animation-timing-function: steps()配合 layout 变更——steps 本身不卡，但和 layout 组合会放大抖动
硬件加速失效的隐蔽原因
即使用了 transform 和 opacity，动画仍卡顿，可能是合成层没真正启用：
- 父元素设置了
overflow: hidden且裁剪了子元素，导致浏览器放弃升层（尤其 Safari） - 元素有
filter（如blur()）、mask或clip-path，部分浏览器会退回到 CPU 渲染 - 开启了
backface-visibility: hidden却未配合transform: translateZ(0)或scaleZ(1)，某些旧版 Chrome 不识别
验证是否升层：选中元素 → Elements 面板 → Styles → 查看 rendering 信息，或在 Layers 面板中确认该元素是否出现在独立图层。
卡顿往往不是单一原因，而是 layout 触发 + 升层失败 + JS 阻塞三者叠加。优先砍掉 layout，再检查层，最后看 JS 调度——顺序错了，调半天也白搭。
