如何利用 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状态、记录日志、清除定时器或隐藏骨架屏——就能安全地利用它，而无需担心它会破坏应用程序整体的错误处理流程。掌握这一点至关重要。
