应使用transform: translateX()替代left做transition，因left触发重排且无法GPU加速，而transform自动启用合成层，配合cubic-bezier曲线和正确初始化可实现流畅轮播。
直接用 transition 配合 left 做轮播位移，在现代项目中不推荐——它容易卡顿、掉帧，且在移动端 Safari 上基本不可靠。
为什么 transition: left 会卡顿
浏览器对 left 的动画必须频繁触发重排（reflow），每次计算都要重新布局整个文档流；它无法自动启用 GPU 合成层，动画完全依赖 CPU 渲染。尤其当父容器有 overflow: hidden 或图片未设宽高时，渲染压力陡增。
- 典型现象：
transition: left 0.5s ease在低端安卓机或 Chrome 90 以下版本中出现首帧延迟、跳变、掉到 30fps 以下 - iOS Safari 对
left过渡几乎没有优化，动画常表现为“一顿一顿” - 若同时读取
offsetLeft或getBoundingClientRect()，还会强制同步回流，进一步恶化性能
如果非要硬用 left，至少得加这些防护
仅限调试或遗留系统兼容场景，生产环境请绕道 transform: translateX()。
- 父容器必须是
position: relative，子项为position: absolute - 手动开启硬件加速：给轮播项加
transform: translateZ(0)或will-change: left（后者仅建议临时开启，长期使用会引发内存泄漏） - 避免在动画进行中动态修改
left的同时操作width、height或display - 确保所有图片有明确宽高（内联或 CSS 指定），防止 DOM 加载完成前
left计算偏移
transition: left 和 transition: transform 的关键差异
二者语法看似相似，底层机制完全不同：
立即学习“前端免费学习笔记（深入）”；
-
transition: left 0.4s→ 触发 layout + paint，无合成层，CPU 渲染 -
transition: transform 0.4s→ 跳过 layout/paint，直接交由 compositor 处理，GPU 加速 - 即使你只改
left，只要元素已存在transform（哪怕只是translateZ(0)），浏览器也会倾向启用合成层——但这是副作用，不是设计保障 -
transform支持 sub-pixel 渲染，left在某些缩放比例下会因取整导致抖动
真正平滑的轮播，从来不是靠“把 left 调得更熟”，而是绕开它。初始化错位、闪动、暂停后抽搐……这些问题在 left 方案里是常态，不是 bug；换用 transform 后，它们多数自然消失——这才是你应该花时间验证的地方。
