uni-app全局Loading封装教程 高效管理请求加载状态

在uni-app应用开发过程中，网络请求的Loading加载提示是实现流畅用户体验的关键环节。这个看似简单的交互功能，若处理不当，极易引发页面响应迟缓、提示频繁闪烁或H5平台样式异常等问题。这些常见故障往往源于对实现细节的疏忽。

uni.request 中集成Loading提示的正确方法

许多开发者倾向于在 uni.request 的 success 或 fail 回调函数中手动管理Loading的显示与隐藏。这种模式存在显著隐患：当请求失败未能触发 success 回调时，uni.hideLoading 可能被跳过，导致加载动画持续显示，造成界面假死，严重影响用户操作。

实现健壮Loading控制的核心原则是：确保在任何请求结果下，Loading状态都能被正确关闭。因此，complete 回调函数是执行收尾操作的理想位置。一个可靠的封装方案应在请求发起前调用 uni.showLoading，并在 complete 回调中无条件执行关闭操作，从而覆盖所有请求路径。

• 务必在发起网络请求前调用 uni.showLoading。为防止用户快速重复点击触发多次请求，建议加入基础的防重复判断机制。
• 绝对避免仅在 success 回调中隐藏Loading，因为网络超时或接口返回错误时，该回调不会执行。
• 若项目中同时使用 uni.showToast 展示错误信息，需注意两者执行的时序。未及时关闭的Loading遮罩层可能会遮挡后续的Toast提示，导致用户无法察觉操作反馈。

请求封装中如何灵活控制Loading显示

是否为所有网络请求默认添加Loading？这种一刀切的策略并不可取。例如，页面下拉刷新、后台静默数据同步、定时心跳包检测等场景，弹出加载框不仅多余，还会干扰用户正常浏览。因此，一个设计良好的请求封装应当支持按需启用或禁用Loading功能。

行业普遍采用的做法是在请求配置参数中增加一个 loading 选项，默认值为 true。当特定业务场景无需加载提示时，显式传入 false 即可禁用。这种方式在保证通用性的同时，提供了充分的灵活性。

export default (params) => {
  const showLoading = params.loading !== false // 默认 true
  if (showLoading) {
    uni.showLoading({ title: params.loadingText || '加载中...' })
  }
  return new Promise((resolve, reject) => {
    uni.request({
      // ...其他配置
      complete() {
        if (showLoading) uni.hideLoading()
      }
    })
  })
}

• 切勿使用全局变量存储Loading状态。在高并发请求场景下，这种方式极易引发状态管理混乱和相互覆盖的问题。
• 可进一步提供 loadingText 参数，允许自定义提示文案，如“提交中…”、“删除中…”、“保存中…”等，使交互反馈更加精准细腻。
• 如果项目中使用的是自定义Loading组件而非官方的 uni.showLoading，需特别注意组件的生命周期管理，确保在请求结束时组件能被正确销毁，防止内存泄漏或残留组件影响性能。

H5端Loading不生效或样式异常的排查与解决

此问题困扰着许多uni-app开发者。其根本原因在于，uni.showLoading 在H5平台是通过动态创建DOM元素模拟实现的。当它尝试将元素注入到 document.body 时，可能与项目中引入的UI组件库（如uView、uni-ui）或自定义的页面布局结构产生样式冲突或层级覆盖。

• 首先，检查 pages.json 的页面配置。若页面设置了 "enablePullDownRefresh": true，在H5端，下拉刷新动画的层级可能会高于Loading提示，导致其被遮挡。
• 其次，对于使用Vue Router并启用路由懒加载的项目，需确保Loading的DOM插入时机早于路由组件的挂载，否则Loading元素可能被后续渲染的页面容器遮盖。
• 在iOS Safari浏览器中，其对 position: fixed 定位元素的层叠上下文处理较为特殊。遇到层级问题时，可尝试为Loading的容器元素添加 transform: translateZ(0) 样式，以强制提升其渲染层级。

处理多请求并发时的Loading重复触发问题

页面初始化时常需并行发起多个数据请求。若每个请求独立控制Loading，会导致屏幕上的加载提示频繁闪烁，这显然不符合设计预期。Loading应代表“页面整体数据加载中”的状态，而非单个请求的进行过程。

解决方案是将Loading的控制权从请求层级提升至页面层级或应用状态管理层级。

• 对于并行发起的多个请求，最优雅的实现是使用 Promise.all。在发起所有请求前统一显示一个Loading，待所有Promise（无论成功或失败）全部完成（settled）后，再统一关闭加载提示。
• 也可在页面的 onLoad 生命周期函数中手动管理：开始加载数据时显示Loading，在所有必需数据都返回后隐藏。
• 在大型复杂应用中，若采用Pinia或Vuex进行状态管理，可在Store中维护一个全局的 loadingCount 计数器。任何请求开始时计数加1，结束时减1。仅当计数器归零时，才真正执行隐藏Loading的操作。这是应对复杂异步依赖场景的终极方案。

最后，需注意一个隐蔽的陷阱：uni.hideLoading 方法本身并非幂等操作。重复调用虽不会报错，但若在封装的 complete 回调中调用了一次，又在业务逻辑中手动调用了一次，可能导致Loading刚显示即被关闭的“抖动”现象。核心原则是：确保每一次 showLoading 都有且仅有一次配对的 hideLoading 调用，并且由同一处核心逻辑掌控其完整的生命周期。