如何用 Promise.prototype.finally 统一处理无论请求成败都必须执行的清理逻辑

今天golang学习网给大家带来了《如何用 Promise.prototype.finally 统一处理无论请求成败都必须执行的清理逻辑》，其中涉及到的知识点包括等等，无论你是小白还是老手，都适合看一看哦~有好的建议也欢迎大家在评论留言，若是看完有所收获，也希望大家能多多点赞支持呀！一起加油学习~

finally 不接收上一个 Promise 的返回值，参数恒为 undefined；清理逻辑（如关闭 loading）应放 finally，业务逻辑（如跳转、存数据）须在 then/catch 或 try/catch 中处理。

finally 不会接收上一个 Promise 的返回值，别指望它能读取响应数据

finally 的设计初衷就是“不管成功失败都执行”，所以它不接收任何参数。你写 finally(res => console.log(res)) 是无效的——res 永远是 undefined。想拿响应体或错误对象，得在 then 或 catch 里处理，或者用 try/catch 配合 await。

常见错误现象：在 finally 里试图调用 res.json() 或判断 res.ok，结果报 Cannot read property 'json' of undefined。

• 清理逻辑（如关闭 loading、重置按钮状态）放 finally 是对的
• 业务逻辑（如跳转、弹提示、存数据）必须放在 then 或 catch 中
• 如果用了 async/await，就别混用 finally，直接用 try { ... } catch { ... } finally { ... }

finally 里不能 return 或 throw，否则会意外改变链式调用行为

finally 的返回值会被忽略（除非它返回一个 pending 的 Promise），但如果你在 finally 里 throw 或 return Promise.reject(...)，它会中断原本的 Promise 链，并把错误抛给下一个 catch —— 这往往不是你想要的。

使用场景：比如你正在封装一个请求函数，希望无论成败都隐藏全局 loading，但又不想影响下游对响应结果的处理。

• ✅ 正确：finally(() => setLoading(false))
• ❌ 危险：finally(() => { if (someCondition) throw new Error('boom'); })
• ⚠️ 隐患：finally(() => Promise.resolve().then(() => doAsyncCleanup())) —— 这会让链变成 pending 状态，下游 then 被延迟执行

与 try/catch/finally 对比：什么时候该选原生 try 语句

当你需要同时访问成功结果和错误原因，又要做统一清理时，try/catch/finally 比链式 then/catch/finally 更直接、更可控。

性能影响几乎可忽略，但可读性和错误定位明显更好——尤其在嵌套多个异步操作时。

• 适合用链式 finally：简单单次请求 + UI 状态清理（如按钮 loading）
• 适合用 try/catch/finally：需要根据响应码做不同跳转、要重试、或清理逻辑本身含异步（比如要等日志上报完成）
• 注意：await 在 finally 块中是合法的，但不要 await 可能 reject 的操作，否则会吞掉原始错误

try {
  const res = await fetch('/api/data');
  const data = await res.json();
  handleSuccess(data);
} catch (err) {
  handleError(err);
} finally {
  setLoading(false);
  // ✅ 安全：同步清理
  // ❌ 避免：await logError(err); —— 会掩盖原始 err
}

finally 在 Promise.allSettled 后的清理时机容易误判

Promise.allSettled 返回的是一个已 resolve 的数组，每个元素带 status 字段。这时候加 finally，它会在整个 allSettled 完成后触发 —— 也就是所有子 Promise 都 settled 后，不是第一个完成就触发。

容易踩的坑：以为 finally 会等每个子请求单独结束，结果 loading 提前关闭，用户看到空白页。

• ✅ 正确理解：Promise.allSettled([p1, p2, p3]).finally(...) 的 finally 只执行一次，且在 p1、p2、p3 全部 settled 后
• ❌ 错误假设：认为它会对每个子 Promise 分别触发
• 如果需要逐个清理（比如每个卡片独立 loading），就得在每个子 Promise 内部各自加 finally，而不是只包一层

真正难的不是写 finally，而是分清“谁负责决策”和“谁负责打扫”。业务分支走 then/catch，收尾动作归 finally；一旦开始在 finally 里做条件判断或异步操作，就说明职责已经混淆了。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。