CSS 动画循环不平滑主因是 ease-in-out 首尾导数为零导致衔接顿挫，应改用 cubic-bezier(0.4,0,0.6,1)或分段缓动；须配合 transform、will-change 优化，并优先排查单次动画质量。
CSS 动画循环不平滑，通常不是因为 animation-iteration-count 或ease-in-out用错了，而是它们的组合方式、关键帧设计或时间函数匹配出了问题。单纯加 infinite 和ease-in-out反而容易在首尾衔接处产生“顿挫感”。
关键问题：ease-in-out 在循环时首尾不连续
ease-in-out让动画从慢到快再到慢，但循环时——上一轮的“结束慢”直接接下一轮的“开始慢”，中间没有速度延续性，视觉上就卡了一下。这不是 bug，是缓动函数本身的数学特性。
- 解决思路：改用
ease-in+ease-out分段控制，或更推荐——用cubic-bezier(0.4, 0, 0.6, 1)（即标准ease）替代ease-in-out，它首尾导数非零，衔接更自然 - 验证方法：把动画时长拉长（比如 5s），打开 浏览器 开发者 工具 的“Animations”面板，勾选“Show timeline”，观察速度曲线是否在 0% 和 100% 处斜率一致
iteration-count 不影响平滑性，但影响调试逻辑
animation-iteration-count: infinite只是让动画重复，并不改变单次播放的过渡质量。如果只循环 2 次就卡顿，说明问题出在单次动画本身；如果只在第 3 次后变卡，可能是 JS 触发了重排或内存泄漏，和 CSS 属性无关。
- 调试建议：先设为
iteration-count: 1，录屏逐帧检查单次动画是否顺滑；确认没问题再开infinite - 注意：不要在
@keyframes里写animation-iteration-count——它只在元素样式中生效，写在规则里会被忽略
真正起效的平滑技巧：关键帧 +transform+will-change
浏览器对 transform 和opacity的动画做了 硬件加速 优化，而 left/top/width/height 等会触发重排，必然卡顿。
立即学习 “ 前端免费学习笔记（深入）”；
- 必须用
transform: translateX()代替left；用transform: scale()代替width/height - 对高频循环动画元素加
will-change: transform（仅限必要时，避免滥用） - 示例写法：
.looping-box {animation: slide 2s cubic-bezier(0.4, 0, 0.6, 1) infinite; will-change: transform; } @keyframes slide {0% { transform: translateX(0); } 100% {transform: translateX(100px); } }
进阶方案：用 steps()或 JavaScript 补位
如果做的是逐帧动画（如加载图标、像素风），ease类函数天生不适用。此时应放弃缓动，改用 steps(8, end) 明确分步，或用 requestAnimationFrame 手动控制帧节奏。
-
steps(4, start)表示 4 步，每步在帧开始时跳变，适合模拟打字、翻页效果 - 纯 CSS 无法实现“循环中动态调整时长或缓动”，这类需求需 JS 介入，例如监听
animationiteration事件微调下一周期参数
