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 但有效）
