animation-iteration-count: infinite 本身不耗电，仅声明循环行为；真正耗电的是动画中使用的CSS属性——transform/opacity安全且GPU加速，top/left/margin等触发重排重绘，加剧移动端发热降频。
animation-iteration-count: infinite 本身不耗电
设置 animation-iteration-count: infinite 这个属性值本身完全不增加 CPU 或 GPU 负载——它只是告诉浏览器“别停”，并不决定动画怎么动、动什么、是否触发重排。真正耗电的是动画里正在变化的 CSS 属性，以及它们引发的渲染流水线行为。
无限循环放大了低效动画的副作用
当动画本就使用 top、left、width、height、box-shadow 或 filter（除 blur 外）等属性时，每一轮循环都会强制浏览器执行：样式计算 → 布局（reflow）→ 绘制（paint）→ 合成。主线程持续满负荷，移动端尤其明显掉温、降频、耗电快。
- ✅ 安全组合（GPU 加速）：
transform（含translate、scale、rotate）、opacity - ❌ 高耗电组合（主线程阻塞）：
top/left、margin、padding、background-color（渐变除外）、filter: drop-shadow() - ⚠️ 伪安全陷阱：
will-change: transform单独加了没用，如果动画本身没用transform，它不会自动启用硬件加速
简写 animation 覆盖 infinite 导致“假无限”并加剧问题
很多人写了 animation-iteration-count: infinite，但紧接着又用 animation 简写覆盖了它，结果动画只播一次，而开发者误以为“无限循环已开启”，于是继续叠加其他高成本动画逻辑，最后发现页面卡顿+发热，却找不到源头。
- 错误写法：
div { animation-iteration-count: infinite; animation: slide 2s ease; }→animation简写会重置iteration-count为默认1 - 正确写法：
div { animation: slide 2s ease infinite; }或分开写但确保无覆盖：div { animation-name: slide; animation-duration: 2s; animation-timing-function: ease; animation-iteration-count: infinite; } - 检查方法：Chrome DevTools → Rendering 面板勾选 “Layout Shift Regions”，看是否有红色闪烁区域
移动端 infinite 动画更需警惕合成层泄漏
无限循环的 transform 动画虽走合成器线程，但如果父容器用了 filter、mask、clip-path 或大量 background-image，整个元素会被降级到软件绘制；更隐蔽的是，多个 infinite 动画共存时，若未控制图层数量（比如每个都加 will-change: transform），GPU 内存压力上升，iOS 上可能触发系统级帧率限制。
立即学习“前端免费学习笔记（深入）”；
- 推荐做法：只对真正需要动画的元素启用
will-change，且 JS 控制动画开始前设、结束后移除 - 替代方案：用
transform: translateZ(0)强制建层比will-change更轻量，但同样不能滥用 - 最容易被忽略的一点：inline 元素（如
<span></span>）做无限旋转时，没加display: inline-block或transform-origin，导致浏览器反复尝试布局回退，电量悄悄跑掉
