用 transform 和 opacity 不卡是因为它们仅走合成层，不触发重排重绘；而 left、top 等会触发 layout→paint→composite 全流程，导致掉帧。
为什么用 transform 和 opacity 就不卡
因为浏览器对这两个属性做了专门的硬件加速路径：它们只走「合成层（compositor Thread）」，不触发重排（layout）和重绘（paint）。而 left、top、width、background-color 一动，就得从 layout → paint → composite 全流程跑一遍，CPU 直接拉满。
- 中低端安卓机上，
transition: left 0.3s可能掉帧到 30fps；换成transform: translateX(100px)，基本稳在 60fps -
opacity动画本身很轻，但若父容器有overflow: hidden+ 子元素用了transform，可能意外阻断合成层提升——这时加will-change: opacity能强制唤醒 GPU 层（但别滥用） - 旧版 android webview（≤4.3）对
opacity+transform组合偶有闪烁，可补一句transform: translateZ(0)或backface-visibility: hidden辅助触发
哪些写法必须立刻替换
不是“建议换”，是只要还在用这些，动画大概率已经拖慢页面了。尤其在响应式切换或 hover 场景下，卡顿会更明显。
-
left: 100px→ 改用transform: translateX(100px) -
top: 20px→ 改用transform: translateY(20px) -
width: 200px→ 若只是视觉缩放，优先用transform: scaleX(2)（注意子元素也会缩放，必要时配transform-origin） -
background-color: #ff0→ 不适合做过渡，改用叠加一层半透明遮罩 +opacity动画更稳妥
容易被忽略的性能陷阱
很多卡顿不是因为用了错的属性，而是“本来该加速，却被悄悄降级”了。
- 对
display: none的元素做opacity过渡无效——它已脱离渲染树；应先设opacity: 0; visibility: visible;，再过渡 - js 里无意读取
offsetTop或getBoundingClientRect()，会强制同步 layout，打断动画流水线，尤其在touchmove中高频发生 - 盲目加
will-change: transform反而更慢：它提前分配图层内存，元素多或生命周期短时，开销大于收益 - chrome DevTools 的 Rendering 面板里勾选 “Layer borders”，看到橙色边框才说明真提升了合成层；没边框？可能是父级写了
transform: none或will-change: auto抑制了它
移动端特别要注意的点
移动端的 touch 事件和默认滚动行为，会让原本流畅的过渡变得“一顿一顿”。
立即学习“前端免费学习笔记（深入）”；
- 给
touchstart/touchmove监听器加{ passive: true }，否则 ios safari 会等 JS 执行完才响应，动画明显延迟 - 如果要阻止原生滚动（比如自定义滑块），别在 handler 里直接
preventDefault()，改用 css 的touch-action: none显式声明 - 避免在 transition 中混用布局属性和合成属性，比如同时写
transition: width 0.3s, opacity 0.3s，浏览器可能整体降级到软件渲染 - 动画时长控制在
0.1s–0.4s之间最自然；太短用户感知不到，太长又像卡住
真正难的不是记住该用哪个属性，而是发现那些藏在 flex 容器里、被一行 JS 读取就触发重排的隐性瓶颈。