移动端加载动画应优先用CSS：轻量、GPU加速、首帧快、无额外资源；Lottie仅适用于必须矢量还原的复杂动效，否则内存与首屏耗时显著增加。
移动端加载动画别硬套Lottie——简单状态切换用CSS，复杂路径才值得上Lottie，否则内存和首屏时间都会明显吃亏。
移动端CSS加载动画为什么更轻量
CSS动画在移动端直接走浏览器合成器线程，transform和opacity属性能触发GPU加速，不占JS主线程。尤其适合环形进度、淡入淡出、缩放弹跳这类基础反馈。
- 首帧渲染快：纯样式解析，
FCP通常压在12ms内（实测Android Chrome 127） - 无额外资源请求：不用加载
lottie-web库（~120KB gzip后），也不用请求JSON文件 - 内存友好：没有图层树管理开销，长时间运行内存增长几乎为零
- 注意兼容点：Android 5.1以下需加
backface-visibility: hidden和transform: translateZ(0)防闪烁
Lottie在移动端的资源代价很具体
不是“不能用”，而是它的开销在移动端会被放大：JSON解析、图层对象树构建、SVG元素批量挂载，全在主线程做。一个中等复杂度的loading.json（约90KB）在低端安卓机上可能吃掉40MB+内存峰值。
- 首次加载耗时 =
lottie-web库下载 + JSON解析 + 渲染初始化，实测平均128ms（比CSS慢10倍） - 内存泄漏风险高：忘记调用
loader.destroy()，动画实例会持续驻留，尤其在频繁路由切换的Capacitor或React Native WebView场景 - SVG渲染器虽保真，但DOM节点爆炸——一个含300个路径的动画可能生成上千个
<path></path>，严重拖慢重排重绘 - Canvas渲染器可缓解DOM压力，但失去CSS交互能力，且iOS Safari对Canvas动画的帧率调度不如Chrome稳定
怎么选：看动画是否“必须矢量”
判断标准不是“好不好看”，而是“能不能被CSS替代”。真实项目里，超过70%的加载动画其实不需要Lottie。
立即学习“前端免费学习笔记（深入）”；
- 用CSS就够了：旋转指示器（
@keyframes spin）、骨架屏渐显（opacity+transition）、按钮波纹（radial-gradient+scale） - 必须用Lottie：设计师交付了带蒙版裁切、修剪路径、多层遮罩的AE动效，且要100%还原——比如Documenso里文档解析过程中的动态墨水流动效果
- 折中方案：Lottie只用于首次冷启动（Splash Screen），进主界面后全部切CSS；或用
lottie-web的renderer: 'canvas'+initialSegment限制播放区间，减少计算量
容易被忽略的细节：销毁时机与降级兜底
很多人写了loader.destroy()，但没考虑它该在什么时候调。在移动端，DOMContentLoaded不等于“页面可用”，尤其有懒加载组件或异步数据请求时。
- 销毁太早：动画还没播完就干掉了，用户看到白屏或卡顿
- 销毁太晚：比如放在
useEffect(() => {}, [])里，但组件已卸载，loader引用丢失，destroy静默失败 - 正确做法：监听Lottie的
complete事件，或结合业务逻辑，在数据加载完成回调里执行销毁 - 务必加降级：网络异常或低端机检测到
lottie-web加载失败时，fallback到CSS版本，不要留空白
