Promise.prototype.finally 是一个在 Promise 无论成功或失败后都必定执行的清理钩子，它不接收任何参数、不干预链式传递的值或错误，也不捕获异常——但正因如此，若在 finally 中抛出新错误，反而会覆盖原始错误，破坏调试溯源；它非常适合关闭加载状态、释放资源等无副作用同步操作，却无法替代 catch 处理错误逻辑或获取响应数据，使用时需格外注意其“无参”“透传”“不兜底”的本质特性，尤其在兼容性处理和错误防御上必须谨慎设计。

Promise.finally 什么时候会被调用

finally 在 Promise 状态变为 fulfilled 或 rejected 后**必定执行**，不关心结果值或错误原因。它不接收参数，也不影响链式返回值——上游的 resolve 值或 reject 原因会原样透传给下一个 then 或 catch。

常见误用是把它当 then(onFulfilled, onRejected) 的简写，但其实它和两者都不同：它不处理结果，也不捕获错误。

finally 中无法获取成功/失败的具体数据

这是最常被忽略的限制：finally 回调函数**没有参数**。你不能在其中拿到 then 的 value 或 catch 的 reason。

• 想清理 loading 状态？可以，finally 很合适
• 想根据请求是否失败做日志上报？不行，得用 catch 单独处理
• 想在 finally 里重试？不能直接访问错误对象，需提前把 error 存到闭包或用 catch 中转

示例：

fetch('/api/data')
  .then(res => res.json())
  .catch(err => {
    console.error('请求失败:', err);
    throw err; // 重新抛出，保持链式状态
  })
  .finally(() => {
    // ✅ 安全：关闭加载动画、释放锁、清理定时器
    hideLoading();
  });

finally 不会阻止错误向下游传播

finally 本身**不会吞掉异常**。如果它内部抛错，或者返回一个被 reject 的 Promise，整个链会立即以该新错误结束（覆盖原始错误）。

• 正常情况：原始 Promise 被 reject → 进入 catch → 再进入 finally → 最终链终止于 catch 的返回值
• 危险操作：在 finally 里写 throw new Error('cleanup failed') → 原始错误丢失，下游只看到 cleanup 错误
• 安全做法：所有可能出错的清理逻辑都用 try/catch 包裹，或确保其为同步且无副作用

反例（破坏错误溯源）：

promise
  .catch(handleError)
  .finally(() => {
    localStorage.removeItem('temp-cache'); // 可能抛 DOMException
  });

兼容性与 polyfill 注意点

Promise.prototype.finally 在 Chrome 63+/Firefox 58+/Edge 18+ 原生支持，但 IE 完全不支持。若需兼容老环境，注意：

• 不要依赖第三方 polyfill 的“增强行为”（比如某些 polyfill 会给 finally 加参数）
• 用标准 polyfill（如 tc39 提案参考实现），它严格遵循无参规范
• 构建工具（如 webpack + babel）开启 core-js/stable/promise 即可
• Node.js 早于 10.0 的版本需手动引入 polyfill

真正容易被绕过的点是：你以为 finally 能替代 then(null, fn)，但它不能处理错误上下文；你以为它像 try/finally 那样绝对可靠，但它内部出错会改写整个 Promise 结果。这些边界必须手写测试覆盖。

今天关于《Promise.finally使用方法详解》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！