Ionic加载动画避坑指南：从LoadingController到骨架屏的完整实践

做Ionic项目的头一年，我被“加载动画”这种基础得不能再基础的点反复教训过。最典型的一次是订单提交页，用户点击后我用了一个普通的全屏loading遮罩，结果在部分Android WebView上，loading闪了不到0.3秒就消失了，页面看起来像卡死，用户又连点了两下提交，后台直接收到三笔相同订单。事后去查，问题根本不是样式，而是loading弹层的生命周期和触发时机没管好。自那以后我把Ionic加载动画当成一个正经课题来研究——它牵扯到的内容远比“放个转圈图片”多得多。

Ionic的加载动画和纯H5还不一样，它跑在WebView里，却要遵守移动端的原生交互规则：返回键、遮罩、页面切换、触摸穿透，任何一个环节出问题，用户体感都是“这App好卡”或者“这按钮没反应”。所以这篇文章不打算只贴一段调用代码，我会从类型区分、内部逻辑、生产环境时序坑、自建品牌动画、性能与无障碍几个维度，把一个看似普通的加载动画讲透。适合正在做Ionic+Angular/React/Vue项目、想把加载体验做稳的人参考。

1. Ionic里的加载动画有三张脸：先分清再用，才不会互相打架

很多新人在Ionic项目里处理加载状态时，习惯性想到“在页面中间放一个转圈”。但Ionic体系下，加载动画至少应该分成三种场景来看：局部按钮/区域反馈、全局模态阻塞、页面数据占位。选错了形态，功能上不一定崩，体验上一定别扭。

1.1 小范围、高频率的反馈：ion-spinner

如果你只是提交按钮、刷新列表、展开某个小组件时需要一个小菊花，优先用 <ion-spinner>。它是一个自带SVG动画的Web Component，不需要你额外准备gif或图片，也不会因为屏幕分辨率放大而变得模糊。

一个常见的用法是放在按钮里，配合 disabled 状态，避免用户重复点击：

html复制<ion-button [disabled]="submitting" (click)="submit()">
  <ion-spinner *ngIf="submitting" name="crescent"></ion-spinner>
  <span *ngIf="!submitting">提交订单</span>
  <span *ngIf="submitting">提交中…</span>
</ion-button>

这里有两个细节值得注意。一是按钮在切换成spinner后，宽度经常会发生跳动，因为“提交订单”四个字和“提交中…”三个字不一边宽，视觉上整个按钮会抖一下。稳妥做法是给按钮一个固定宽度，或者用 min-width 预留空间。二是不要把 <ion-spinner> 当成全局loading用，它没有遮罩、不拦截点击，如果你在页面中间放一个spinner，用户依然可以点到下面的按钮和列表，这在业务上是很危险的。

1.2 全屏级、带遮罩的“打断式”反馈：LoadingController

当一个操作需要全局等待，比如提交订单、拉取用户初始化信息、生成报告，这时候用户不应该再操作底层页面，Ionic官方给出的答案是 LoadingController，它对应的底层组件是 ion-loading。

很多人没意识到的是，ion-loading 并不是你在模板里写一行 <ion-loading></ion-loading> 就能用的组件，它必须通过Controller创建。原因是它属于Ionic的Overlay体系，跟 ion-alert、ion-toast 一样，需要被动态挂载到App根节点上方，天然自带遮罩层、入场/退场动画以及与系统返回键的交互逻辑。如果你绕过Controller自己用 *ngIf 在页面里渲染一个半透明遮罩，就等于放弃了这些底层能力，后面所有生命周期问题都要自己处理。

1.3 数据占位、进度条与更多选择

第三种形态往往被忽略：页面首屏数据加载。比如进入订单列表，接口要1秒才能返回，这时如果你放一个全屏loading，用户看到的是“白屏-转圈-突然弹出一堆列表”，观感很差。更好的做法是用骨架屏占位，也就是 ion-skeleton-text，让用户在数据回来之前就看到页面的大致结构。Ionic 6+内置了骨架屏组件，配合 animated 属性会有渐变扫光效果。

所以我的建议是：先别急着写代码，判断这次加载是“操作反馈”还是“内容占位”。如果是按钮触发的异步任务，用spinner或loading弹层；如果是页面初始数据加载，用骨架屏；如果是上传下载这种有明确进度概念的，用 ion-progress-bar 反而比转圈更直观。加载动画不是越复杂越好，而是越符合用户对当前任务的预期越好。

2. LoadingController的API盘点：从调用姿势到定制边界

如果你决定用 LoadingController 做全局阻塞反馈，那接下来就要把它这套API吃透。光看文档时觉得很简单，无非三行代码，但真正用起来，每个参数都对应一类产品需求。

2.1 标准三段式：create、present、dismiss

基本调用流程是这样的：

typescript复制async submit() {
  const loading = await this.loadingCtrl.create({
    message: '正在提交订单…',
    spinner: 'crescent',
    backdropDismiss: false
  });

  await loading.present();

  try {
    await this.api.createOrder();
    await this.router.navigate(['/order-success']);
  } finally {
    await loading.dismiss().catch(() => {});
  }
}

很多踩坑都出在“create、present、dismiss都是异步方法”这件事上。create 只是把配置转成一个组件实例，做DOM准备工作，页面还没出现；present() 才会把loading挂载到页面上并播放入场动画；dismiss() 则会播放退场动画并销毁实例。

如果你的代码里没有等待这些异步方法完成，比如在某个回调里直接调用了 loading.dismiss()，而此刻 present() 还没执行完，就会得到“闪一下就消失”或者“dismiss called before present”的诡异现象。所以我的习惯是：把当前loading实例保存为组件属性，所有对它的操作都加上 await，并在 dismiss 时用 .catch(() => {}) 兜底，因为一个已经被销毁的实例再次调用dismiss会直接reject。

2.2 参数取舍：message、duration、backdropDismiss 到底怎么配

message 是最直观的文案参数，但它的定位是纯文本。有的团队想把message里塞一段带颜色的HTML，比如 <span style="color:red">拼命加载中</span>，这在默认配置下不会生效，因为Ionic不会把message当成HTML渲染，这是为了防止XSS注入，是安全设计。如果你确实需要富文本内容，应该用 component 参数传入自定义组件，后面第四章会讲。

duration 参数是“自动关闭”，设了3秒就是3秒后loading自己消失。我强烈建议不要把一个需要用户等待网络结果的操作交给 duration 自动关闭。原因是网络请求没那么准时，如果3秒内没回来，loading就消失了，用户会以为已经加载完，结果页面上什么都没有；如果1秒就回来了，loading还要硬生生转满3秒，用户会觉得这App真慢。duration 更适合用在纯提示性、且你确定不需要用户交互的场景，比如“同步成功2秒后消失”。

backdropDismiss 是一个非常关键的业务开关。它决定了用户点击遮罩区域时，loading会不会被关掉。很多业务里loading弹出来是为了锁住页面，防止用户重复操作，这种情况下必须设成 false，否则用户一点遮罩，loading没了，底层按钮又能点了，等于没锁。反过来，如果loading只是轻量提示，允许用户随时取消，那设成 true 才合理。

2.3 spinner类型、CSS变量与样式上限

spinner 参数支持多种类型，比如常见的 lines、lines-small、crescent、dots、bubbles、circles。不同类型视觉风格差异很大：crescent 是单弧线在转，简洁利落；dots 是几个点循环跳动，偏活泼；lines 系列更像iOS系统风格。如果你不指定，Ionic会根据当前平台mode自动选默认值，这就是为什么你有时候在iOS上看到线条、在Android上看到月牙，不是代码写错了，是平台默认行为。

如果需要把默认转圈颜色改成品牌色，官方提供了CSS变量，不需要深挖内部样式：

css复制.my-loading-overlay {
  --spinner-color: var(--ion-color-primary);
  --backdrop-opacity: 0.5;
}

然后在create时传入cssClass：

typescript复制await this.loadingCtrl.create({
  cssClass: 'my-loading-overlay',
  spinner: 'crescent'
});

常用的CSS变量大致是下面几个：

这套变量能满足80%的简单换色需求。但如果你想做更复杂的动画，比如品牌Logo心跳、文字逐字浮现、多段动画串联，默认spinner就走不通了，因为它本身是封装好的SVG动画，你能控制的只有开关和颜色。到这一步，你需要走自定义component的方案。

3. 生产环境里最容易暴雷的三个时序场景

写demo的时候，loading怎么调都正常。真正上线以后，各种“loading不消失”“loading闪一下就没”“用户绕过了loading”的问题才会冒出来。我自己遇到的高频问题集中在三个场景：并发请求、Android返回键、路由跳转。这三个场景本质都不是样式的锅，而是时序和生命周期。

3.1 loading闪一下就没：关于并发请求和二次dismiss

很多项目会封装一个全局loading服务，在发送网络请求前 show()，请求结束后 hide()。如果一次只发一个请求，一切正常；但页面经常会有两个以上接口并发，比如进入详情页同时拉详情、拉推荐列表、拉用户状态，三个请求各自在回调里调用了 hide()，第一个请求回来就把loading关了，后面两个虽然还在路上，用户却已经看到半成品页面。

再严重一点的情况是，两个请求基本同时结束，hide() 被连续执行两次，第二个hide去dismiss一个已经被销毁的loading实例，这时候Ionic会抛“overlay was dismissed”的警告，有些版本的WebView甚至会直接打印一堆红色错误，看着像Crash了，其实没有，但很吓人。

正确做法是给loading服务加引用计数。多个show同时发生，只在第一个show时真正present；每次hide只做计数减一，计数归零时才真正dismiss。类似这样：

typescript复制export class LoadingService {
  private count = 0;
  private loadingEl?: HTMLIonLoadingElement;

  async show() {
    this.count++;
    if (this.loadingEl) {
      return;
    }
    this.loadingEl = await this.loadingCtrl.create({
      message: '加载中…',
      spinner: 'crescent',
      backdropDismiss: false
    });
    await this.loadingEl.present();
  }

  async hide() {
    this.count = Math.max(0, this.count - 1);
    if (this.count > 0 || !this.loadingEl) {
      return;
    }
    const el = this.loadingEl;
    this.loadingEl = undefined;
    await el.dismiss().catch(() => {});
  }
}

与此同时，我建议给loading加一个超时兜底，比如30秒后强制关闭，防止某个请求挂在半路不返回、也不走catch，loading永远转下去。移动端网络环境复杂，弱网、断网、代理切换都可能让Promise长时间pending，没有超时机制就等于把用户锁死在loading页里。

3.2 Android返回键和背景点击：别让用户手动“跳车”

Android实体返回键和IOS的边缘滑动返回，对Overlay体系的组件有不同处理。Ionic默认允许返回键关闭多数弹层，包括loading。这在某些业务场景下是一个大坑：用户在提交订单，loading正在转，他以为卡住了，按了一下返回键，loading消失了，页面看似回到了上一页，但底层那个网络请求并没有被取消——它还在飞。过了一秒订单创建成功了，后台多了一笔订单，用户却已经离开页面，完全不知道结果。

如果你希望loading承担“流程锁定”的作用，就一定要意识到：锁住界面的不只是那层半透明遮罩，还包括系统返回行为。Android上返回键需要被拦截或至少被感知。常见的处理思路是，针对那种不允许中途取消的loading，把 backdropDismiss 设成false，同时用平台返回键监听做条件判断：

typescript复制this.platform.backButton.subscribeWithPriority(9999, () => {
  if (this.loadingService.isVisible()) {
    // 这里可以什么都不做，或者弹一个“确认取消吗”的对话框
    return;
  }
  this.navCtrl.back();
});

这个优先级要足够高，否则Ionic内部对overlay的返回键处理会先执行，然后直接把loading关了。实际项目里还要根据业务决定：如果用户明确想取消，是不是该给他取消的入口？有些场景建议做成“再按一次确认取消”，有些场景建议直接阻止返回，只保留页面上的取消按钮。没有绝对正确答案，但你不能不做处理，否则返回键就是流程的一个后门。

3.3 路由跳转与页面卸载：overlay不会自动跟着页面走

前端路由和loading弹层的矛盾非常隐蔽。Angular路由切换时，当前页面的组件会被销毁，但通过 LoadingController 创建的overlay实例并不会自动跟随组件销毁——因为它挂在根节点或者某个高阶容器上，不受当前页面路由控制。

于是出现这种场景：用户进入列表页，列表接口在请求，loading正常转着。此时用户等不及，快速点了返回。列表页组件销毁了，但loading还稳稳地悬在上一页或者首页上方，用户怎么点都消不掉，除非杀进程。原因就是你忘了在组件离开前清理loading。

针对这个问题，我一般会在页面的 ionViewWillLeave 或Angular的 ngOnDestroy 里做一个统一清理动作，把服务里保存的loading实例直接dismiss掉：

typescript复制ionViewWillLeave() {
  this.loadingService.clear();
}

另一个更隐蔽的问题是，假设你的业务逻辑是“接口成功后再跳转路由”，比如提交订单成功后 router.navigate 到支付页，这个跳转又触发了支付页自己的loading，两个overlay可能叠加出现，视觉上像卡死一样闪一下。整理方案只有一个原则：overlay的生命周期要显式管理，凡是新建了loading的地方，都要明确在哪个节点关闭、由谁关闭，别指望组件析构帮你回收。

4. 自建品牌加载动画：从零做一个能融入设计稿的loading

默认spinner用时间长了，产品经理一定会拿着设计稿来说：“这个转圈不好看，换成咱们的Logo呼吸动画吧。”到这一步，不是不能实现，而是要看你怎么实现。我见过最痛苦的做法是直接去改Ionic内部的SVG，结果一次版本升级全被覆盖。正确姿势是利用 LoadingController 的component机制，把自定义组件像积木一样塞进overlay。

4.1 为什么选loadingCtrl.create的component方案，而不是魔改默认spinner

HTMLIonLoadingOptions 里除了message、spinner之外，还有一个容易被忽略的 component 参数。它的作用是：你可以在loading弹层内部渲染任意一个Angular/React/Vue组件。这样动画样式、文字排版、颜色全部由你自己控制，而不是被限制在spinner的几种内置动画里。

typescript复制const loading = await this.loadingCtrl.create({
  component: BrandLoadingComponent,
  componentProps: {
    tip: '正在生成报告'
  },
  backdropDismiss: false,
  cssClass: 'brand-loading'
});

await loading.present();

这个方案有几个天然好处：第一，Ionic的遮罩、入场退场动画、返回键管理仍然生效，你不用自己手写一套遮罩；第二，组件内部可以用真正的CSS/SVG动效，不受内置spinner约束；第三，组件代码和普通页面组件完全一致，能使用框架的依赖注入、状态管理，升级Ionic版本也不怕内置SVG被改。

相比之下，去覆盖默认样式极容易踩坑。因为ion-loading内部结构是shadow DOM隔离的，外部普通CSS根本渗透不进去，强行用 ::ng-deep、!important 或一些hack去改，能跑但很脆，一升级就崩。

4.2 组件结构和动画实现

做一个品牌loading组件，核心是一个容器、一个动画图案、一行文案。这里以一个简单但耐看的环形Logo动画为例，结构大致是这样：

html复制<div class="brand-loading-box">
  <div class="logo-area">
    <svg viewBox="0 0 64 64">
      <circle class="ring-bg" cx="32" cy="32" r="28"></circle>
      <circle class="ring-fg" cx="32" cy="32" r="28"></circle>
    </svg>
    <div class="logo-icon">A</div>
  </div>
  <div class="brand-tip" *ngIf="tip">{{ tip }}</div>
</div>

CSS部分，让外圈圆环像进度一样绕圈：

css复制.ring-bg {
  fill: none;
  stroke: rgba(0, 0, 0, 0.08);
  stroke-width: 4;
}

.ring-fg {
  fill: none;
  stroke: var(--ion-color-primary);
  stroke-width: 4;
  stroke-linecap: round;
  stroke-dasharray: 130;
  stroke-dashoffset: 130;
  transform-origin: center;
  animation: drawRing 1s ease-out forwards, spinRing 1.4s linear infinite;
}

@keyframes drawRing {
  to {
    stroke-dashoffset: 0;
  }
}

@keyframes spinRing {
  from {
    transform: rotate(0deg);
  }
  to {
    transform: rotate(360deg);
  }
}

这里的动画同时做了两件事：先画出一个完整的圆环，再让圆环整体旋转。加上中间Logo的点缀，观感上比默认spinner有质感得多。文案部分还可以加一个轻微的呼吸动画，让“正在生成报告”这几个字不显得死板。

注意颜色不要写死，尽量用 var(--ion-color-primary) 这样的Ionic主题变量，这样App切深色模式或者换主题色时，loading会跟着变化，不用额外维护。

4.3 自定义组件进入Ionic Overlay后的三个坑

第一个坑是样式隔离。如果你用的是Angular，组件默认的ViewEncapsulation.Emulated会生成带 _ngcontent 属性的样式，这个没问题。但如果你在全局样式文件里写 .brand-loading-box 想覆盖组件内部样式，大概率会失效，因为Ionic把组件动态渲染到了全局Overlay容器里，封装关系和普通页面组件不完全一样。所以自定义loading组件的样式最好都写在组件自己的样式文件里，别依赖全局类名控制内部。

第二个坑是变更检测。默认Ionic Overlay把组件实例化并放入一个并非当前路由页的容器中，如果你这个自定义组件用了 OnPush 变更检测策略，且需要根据接口状态动态更新提示文案，可能会出现页面已经变了但loading文案不更新的情况。这时你需要主动触发变更检测，常见做法是在组件里注入 ChangeDetectorRef，在数据到达后调用 markForCheck()。

第三个坑是组件销毁时的事件清理。自定义loading组件内部如果订阅了某个服务、监听了某个事件，需要在组件的 ngOnDestroy 里取消订阅，否则loading每次打开关闭，都会残留一个订阅者。这个问题早期很难发现，直到你发现在某个页面疯狂开关loading几十次之后，内存占用一直涨，或者事件触发了多遍，才意识到是这里漏了清理。

5. 从“能转”到“好用”：骨架屏替换、全局Loading调度与无障碍适配

最后这部分与其说是经验，不如说是我在真实项目里沉淀下来的一套取舍标准。加载动画的本质是缓解用户等待焦虑，但并不是所有等待都要转圈，也不是转得越花哨越好。

5.1 骨架屏不是取代所有loading，而是分流“页面数据加载”

Ionic自带的 ion-skeleton-text 做页面首屏占位非常好用。比如进入一个列表页，展示三条灰色占位行，每条里面有几个不同宽度的灰色圆角条，配合 animated 属性会有扫光效果，让用户觉得页面正在“长出来”，而不是卡住了。

html复制<ion-list>
  <ion-item *ngFor="let item of [1, 2, 3]">
    <ion-avatar slot="start">
      <ion-skeleton-text animated></ion-skeleton-text>
    </ion-avatar>
    <ion-label>
      <h3>
        <ion-skeleton-text animated style="width: 50%"></ion-skeleton-text>
      </h3>
      <p>
        <ion-skeleton-text animated style="width: 80%"></ion-skeleton-text>
      </p>
    </ion-label>
  </ion-item>
</ion-list>

骨架屏和loadingController的分工大概是：打开一个新页面时，如果核心内容需要时间加载，优先展示骨架屏，让用户尽快感知页面结构；当用户主动点击提交、确认这类按钮时，才用全屏loading锁住操作。如果把这两个场景反过来——打开页面时转圈、点击提交时出现一片灰色骨架，那体验就全乱了。

5.2 全局HTTP并发下的Loading调度与超时兜底

真实项目里的loading往往不是手动在页面里调，而是封装在HTTP拦截器里，请求一发出就show，请求一返回就hide。但接入了多个接口后，你会发现必须处理并发、短请求闪烁、请求永不返回三个问题。

并发用上面说的引用计数解决。短请求闪烁可以这样处理：不是马上present，而是delay 200到300毫秒后如果请求还没结束再present。这个体验很关键，如果接口平均只要100毫秒就返回，你根本不需要转圈，一闪烁反而显得页面很笨重。可以用一个简化的“最短展示时间”策略：即使请求很快结束，也让loading至少展示400毫秒，再优雅退出，避免刚出现就消失的闪烁感。

超时兜底是很多团队会忽略的。移动端App随时可能遇到弱网，一个请求卡了30秒甚至更久的时候，产品预期应该是出现错误提示或者超时按钮，而不是永远转下去。因此我写的loadingService里，每次show都会启动一个定时器，超过比如20秒就强制dismiss并抛出一个可识别的超时标记，由页面决定是跳转错误页还是弹提示：

typescript复制if (timeoutId) {
  clearTimeout(timeoutId);
}
timeoutId = setTimeout(() => {
  this.forceClose();
}, 20000);

这一步能救回很多用户的耐心，也避免loading成为“永远关不掉的遮罩”。

5.3 WebView里的动效性能和无障碍偏好

最后说两个容易忽略但很影响口碑的点。一个是动画性能。Ionic的加载动画跑在WebView里，不是原生渲染，CSS动画如果频繁触发重排，在低端Android机上会非常卡。给所有动画元素只使用 transform 和 opacity，尽量避免动画改变 top、left、width 这些触发layout的属性。像上面环形动画的旋转，就是标准做法。这也是为什么很多Ionic组件内部动画都用CSS transform实现，因为它在Android WebView上的合成效率更高。

另一个是系统的“减弱动态效果”无障碍设置。部分用户会在手机设置里开启“移除动画”或“减弱动态效果”，如果App无视这个偏好，还在那煞有介事地转圈，对这类用户其实是种负担。可以通过 window.matchMedia('(prefers-reduced-motion: reduce)') 来检测，如果用户开了这一项，创建loading时主动关闭或缩短动画：

typescript复制const reduceMotion = window.matchMedia(
  '(prefers-reduced-motion: reduce)'
).matches;

const loading = await this.loadingCtrl.create({
  ...options,
  animated: !reduceMotion,
});

这样既不破坏功能，又尊重了用户的系统级偏好，在无障碍评测和用户口碑上都是加分项。

我现在维护的Ionic项目里，加载动画已经完全沉淀成了一套独立服务：页面首屏数据用骨架屏，按钮操作走局部spinner，全局流程走带引用计数的自定义loading组件，所有打开过的loading都记录在统一的实例里，路由离开时自动清理，超时时强制关闭。新同事接手页面时基本不需要理解背后的故事，直接调service就行。如果你的项目还在每个页面里手动 create 一个 HTMLIonLoadingElement，然后到处处理它的销毁逻辑，那我建议尽早往这个方向收敛。网上关于Ionic加载动画的讨论大多数停留在“怎么让默认转圈跑起来”，但生产环境真正的门槛，是后面这些没人写进文档的时序和生命周期问题。