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事件微调下一周期参数