如何用 Promise.prototype.finally 统一处理无论请求成功还是失败都要隐藏的骨架屏

如何利用 Promise.prototype.finally 统一隐藏骨架屏，无论请求成功或失败

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

为什么 Promise.prototype.finally 是隐藏骨架屏的理想选择

核心原因在于其设计初衷：finally 方法专为执行“最终清理”任务而生。它不关心前一个 Promise 最终是成功兑现（fulfilled）还是被拒绝（rejected），只要 Promise 状态“已敲定”（settled），它就一定会执行。这完美匹配了“无论接口请求结果如何，最终都必须关闭骨架屏”的通用前端需求。

此外，finally 不接收任何参数，这保证了它不会意外修改链式调用传递下来的值，同时也不会吞噬上游抛出的错误。相比之下，在 then 和 catch 回调中分别编写隐藏骨架屏的逻辑，不仅会造成代码重复，还容易因遗漏导致界面卡住。finally 提供了一种更简洁、更可靠的一体化解决方案，有效提升代码可维护性。

在 fetch 请求中正确应用 finally 来关闭骨架屏

理解了原理，但实践中仍可能出错。一个常见误区是将 finally 仅放在错误处理分支之后，而忽略了成功处理链路中也可能抛出异常（例如 JSON 解析失败），这会导致骨架屏在某些情况下无法隐藏。

正确的做法是，将 finally 置于整个 Promise 链的末端，作为最终的、必然执行的清理步骤：

showSkeleton();
fetch('/api/data')
  .then(res => {
    if (!res.ok) throw new Error(`HTTP ${res.status}`);
    return res.json();
  })
  .then(data => render(data))
  .catch(err => handleError(err))
  .finally(() => hideSkeleton()); // 确保在任何情况下都会执行

当然，使用async/await语法也非常普遍。需要注意的是，finally不能直接跟在await表达式后面，此时经典的try...catch...finally语句块就成为了最佳选择：

showSkeleton();
try {
  const res = await fetch('/api/data');
  const data = await res.json();
  render(data);
} catch (err) {
  handleError(err);
} finally {
  hideSkeleton(); // 同样是最终的收尾位置
}

注意：在 finally 中修改共享状态可能引发竞态条件

这是在处理并发请求时容易遇到的进阶问题。设想一个场景：页面同时发起多个请求，它们共享同一个骨架屏的加载状态（例如一个全局的 isLoading 变量）。如果每个请求都在自己的 finally 回调中直接设置 isLoading = false，那么最先完成的请求会过早地关闭骨架屏，而此时其他请求可能仍在加载，导致页面状态混乱，用户体验受损。

如何解决这个并发请求下的骨架屏管理难题？以下是几种有效的策略：

• 采用请求计数器：发起请求时执行 pendingCount++，在 finally 回调中执行 pendingCount--，并仅在计数器归零时，才真正执行隐藏骨架屏的操作。
• 借助现代状态管理工具：使用 AbortController 进行精细的请求控制，或者直接采用如 React Query、SWR、VueUse 等前端数据请求库，它们内置了智能的 Loading 状态管理，能自动处理并发场景。
• 从架构设计上隔离状态：避免使用全局共享的加载状态，改为让每个独立的 UI 组件或视图模块维护自身的 isPending 状态，由前端框架（如 React、Vue）来协调最终的渲染逻辑。

finally 不会阻止错误传播，但需警惕其潜在影响

这是一个关键但常被误解的特性。finally 执行完毕后，原始的 Promise 拒绝原因并不会被“消化”或阻止，它仍然会继续向调用链的上层传播。也就是说，finally 本身并非错误处理器。

然而，有一个重要的细节：如果你在 finally 回调函数内部主动 throw 了一个新的错误，或者返回了一个被拒绝的 Promise，那么这个新产生的错误将会取代并覆盖掉链中可能存在的原始错误。反之，如果 finally 回调正常执行完毕，则完全不影响错误的原有传播路径。因此，下面这种写法是安全的：

fetch('/api/data')
  .then(handleSuccess)
  .catch(handleError) // 在此处捕获并处理错误
  .finally(() => hideSkeleton()); // ✅ 执行后，任何未被捕获的错误仍会正常向外抛出

而下面这种写法则会带来问题，因为它掩盖了原始错误：

.finally(() => {
  hideSkeleton();
  return Promise.reject(new Error('finally broke it')); // ❌ 这个新抛出的错误会覆盖掉链中任何原有的错误信息
})

总而言之，在实际前端开发中，只要牢记finally最适合用于执行那些不改变最终结果、无副作用的“清理”操作——例如更新DOM状态、记录日志、清除定时器或隐藏骨架屏——就能安全地利用它，而无需担心它会破坏应用程序整体的错误处理流程。掌握这一点至关重要。