17370845950

是的，但仅设 infinite 不足以实现无缝循环，需配合 animation-fill-mode: forwards 及 keyframes 中 0% 和 100% 状态完全一致，否则会出现跳变；infinite 下 animationend 永不触发，且 iOS 15.4 前存在 Safari 兼容性陷阱。

animation-iteration-count 设为 infinite 就能无限循环？

是的，但仅设 infinite 不足以让动画真正“无缝循环”。常见现象是：动画播完一帧后突然跳回起点，再重新开始——这不是视觉意义上的循环，而是重置式播放。根本原因在于没配合 animation-fill-mode 和关键帧设计。

• animation-iteration-count: infinite 只控制播放次数，不干预起始/结束状态
• 默认 animation-fill-mode: none，意味着动画结束后元素立刻恢复初始样式
• 若 @keyframes 的 0% 和 100% 状态不一致，且未用 forwards 锁定末态，就会出现“抽搐”感

如何避免循环时的视觉跳变

关键在三者协同：迭代次数 + 填充模式 + 关键帧首尾一致性。尤其注意 100% 必须显式定义，不能依赖浏览器自动插值补全。

• 始终显式写出 0% 和 100% 的完整声明，哪怕值相同
• 搭配 animation-fill-mode: forwards，让最后一帧样式持续生效（否则无限循环下“最后”并不存在，但 forwards 仍作用于每一周期的末尾）
• 若动画需“平滑衔接”，0% 和 100% 的所有相关属性必须完全一致（如 transform、opacity、color）

@keyframes slide-loop {
  0% {
    transform: translateX(0);
    opacity: 1;
  }
  50% {
    transform: translateX(100px);
    opacity: 0.8;
  }
  100% {
    transform: translateX(0); /* 必须写，不能省略 */
    opacity: 1;               /* 必须与 0% 完全一致 */
  }
}

infinite 和数值之间的行为差异

设为具体数字（如 3）和 infinite 在底层触发逻辑不同：前者有明确终点，后者由渲染引擎持续调度。这会影响 JavaScript 对动画状态的监听。

• animationiteration 事件在每次循环开始时触发（包括第 1 次），infinite 下该事件会持续触发；而数值型只触发 n−1 次（如 3 次则触发 2 次）
• animationend 事件：数值型会在最后一次循环结束时触发；infinite 下**永不触发**——这点常被忽略，导致监听逻辑失效
• 性能上，infinite 不会比数值型更耗资源，但若关键帧内含大量计算（如 calc() 嵌套过深），长期运行可能加剧重排压力

移动端 Safari 中 infinite 动画的兼容性陷阱

iOS 15.4 之前版本存在一个隐藏问题：当 animation-iteration-count: infinite 配合 will-change: transform 时，动画可能在几秒后意外暂停，且不触发任何事件。这不是 bug 报告里的典型 case，而是渲染管线调度异常。

• 临时规避：去掉 will-change，或改用 transform: translateZ(0) 强制硬件加速
• 更稳妥做法：用 animation-duration 配合 JS 定时重置 animation-name（即“伪无限”），虽增加代码量，但可控性强
• 检测方式：在 animationiteration 回调里记录时间戳，若间隔突增 >2×duration，基本可判定 Safari 渲染挂起

实际项目里，无限循环动画最易出问题的不是写法本身，而是把它当成“设置完就不用管”的黑盒——它和 DOM 生命周期、页面可见性、设备节电策略都存在隐式耦合。