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 的问题，而是浏览器等待确认是否为双击或滚动操作。
