是的，但仅设 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 生命周期、页面可见性、设备节电策略都存在隐式耦合。
