不能直接对margin做动画，因其是布局属性，每帧变化均触发重排，导致CPU开销大、卡顿掉帧；应改用transform: translateX()等合成属性实现相同视觉效果，仅触GPU合成，不重排不重绘。
为什么不能直接对margin做动画
因为margin是布局属性，每次变化都会触发浏览器重排（reflow）——它要重新计算元素在文档流中的位置、尺寸，连带影响兄弟/父级元素。动画过程中每帧都重排，CPU开销大，尤其在低端设备或复杂页面里，很容易卡顿甚至掉帧。
transform: translate()怎么替代margin-left
用transform: translateX()实现向右位移，视觉效果一致，但只操作图层合成，不改变文档流，也不触发布局计算。关键点有三个：
- 必须搭配
transition: transform，不能写transition: all或transition: margin-left - 起始状态要显式声明
transform: translateX(0)，否则从无到有的首次动画可能跳变 - 如果元素本身是
float或inline，translate依然生效，且不影响其他浮动元素的排列
示例：
.btn { transition: transform 0.3s cubic-bezier(0.25, 0.8, 0.25, 1); }<br>.btn:hover { transform: translateX(12px); }
什么时候需要加will-change: transform
仅当该元素动画频繁（比如轮播图、拖拽反馈、实时滚动指示器），且你观察到 Chrome DevTools 的「Layers」面板里没生成独立合成图层时，才加。它只是提示浏览器“这个元素要动了”，提前创建图层；滥用会导致GPU内存浪费，反而拖慢整体渲染。
立即学习“前端免费学习笔记（深入）”；
更轻量的替代方案是transform: translateZ(0)或transform: translate3d(0, 0, 0)，它们也能触发图层提升，兼容性更好，但语义不如will-change清晰。
混用transform和margin会怎样
千万别在同一个动画周期里既改margin-left又改transform。比如transition: margin-left 0.3s, transform 0.3s——前者强制重排，后者虽走合成，整条动画链仍会被拉回CPU渲染，GPU加速失效。性能退化成“看起来流畅，实则更耗电”。
真正要兼顾布局与动画时，优先重构结构：用position: relative + left？不如直接上transform；要用Flex/Grid控制初始位置？那就别在动画阶段切回margin。
最常被忽略的一点：即使写了transform: translateX(10px)，如果父容器设置了overflow: hidden且子元素超出边界，动画中可能被意外裁剪——这不是性能问题，但会让位移“消失”，得检查裁剪上下文。
