ease-in-out 动画卡顿主因是重排、未启用硬件加速及曲线非对称;应仅用 transform/opacity,配合 will-change 或 translate3d 启用 GPU 渲染,并用 cubic-bezier 自定义更平滑曲线。

为什么 ease-in-out 动画看起来还是卡顿?
直接写 transition: transform 0.3s ease-in-out 并不总能获得预期的平滑效果。常见原因是动画触发了重排(reflow),或元素未启用硬件加速,导致浏览器被迫用软件渲染。尤其是位移类动画,transform 必须搭配 will-change: transform 或 translateZ(0) 才能稳定走 GPU 合成管线。
- 确保动画属性只使用
transform和opacity,避免触发动画期间的top/left/width等会引发重排的属性 - 对频繁动画的元素加
will-change: transform,但不要滥用——仅在动画开始前 1–2 帧设置,结束后及时清除(可用transitionend事件清理) - 若兼容性要求宽松,优先用
transform: translate3d(0, 0, 0)替代translateZ(0),更明确地启用 3D 上下文
ease-in-out 的实际曲线并不对称
很多人误以为 ease-in-out 是“先缓入再缓出”的完美镜像曲线,其实它的缓入段比缓出段略长,且起始/结束加速度并非为零——这在快速连续动画中容易暴露“弹跳感”。真正可控的方式是用 cubic-bezier() 自定义。
- 标准
ease-in-out等价于cubic-bezier(0.42, 0, 0.58, 1),可复制进 chrome DevTools 的 timing function 编辑器直观对比 - 追求更自然的物理感,试试
cubic-bezier(0.34, 1.56, 0.64, 1)(常用于 Material Design 的“decelerate”曲线) - 若动画需多次循环,避免用
ease-in-out+infinite,因首尾速度不匹配会导致跳变;改用ease或自定义对称贝塞尔值如cubic-bezier(0.25, 0.46, 0.45, 0.94)
移动端 touch 触发的位移动画延迟问题
在 ios safari 或部分安卓 webview 中,touchstart 后立刻触发 transform 动画,常有 100–300ms 延迟。这不是 ease-in-out 的问题,而是浏览器等待确认是否为双击或滚动操作。
- 给容器加
touch-action: manipulation,能禁用双击缩放和延迟识别,让 touch 事件立即响应 - 避免在
touchstart中直接修改style.transform,改用classList.toggle()切换预设 class,让 css 引擎提前编译动画帧 - 若需 js 控制动画进度(如拖拽跟随),用
requestanimationFrame更新transform,而非同步赋值
动画中断时的过渡衔接失效
用户快速反复 hover 或点击时,ease-in-out 动画可能被新 transition 覆盖,造成“抽搐”或瞬间跳回原位置。这是因为 CSS transition 不会自动插值当前动画状态,而是从当前渲染值重新开始。
立即学习“前端免费学习笔记(深入)”;
- 用
getComputedStyle(el).transform读取当前矩阵,在 JS 中计算中间态并手动设置,适合精细控制场景 - 更轻量的方案:统一用
animation+@keyframes替代transition,配合animation-fill-mode: forwards和animation-play-state管理中断 - 简单交互场景下,加一个极短的
transition-delay: -0.001s可强制浏览器复用上一帧状态(hack 但有效)
真正影响平滑度的,往往不是贝塞尔曲线本身,而是动画是否落在合成层、是否被主线程阻塞、以及中断时的状态管理逻辑。这些细节在调试面板里看不到,但每一处都决定用户手指划过屏幕时的体感。