async函数中.finally代码块执行时机疑问：两种写法为何结果不同？

你碰到的是JavaScript async函数里try-finally和Promise返回值的正常交互逻辑，两种写法的核心差异在于对fn()返回Promise的处理方式：

第一种写法为什么没执行releaseResources #

const withinScope = async(fn)=>{
  try{
    return fn()
  }finally{
    await releaseResources()
  }
}

当fn()返回Promise时，return fn()会直接把这个Promise当成withinScope的返回值抛给调用者。这里的关键问题是：

• 如果fn()的Promise快速reject（比如同步抛出错误、或者异步操作立刻失败），且你调用withinScope时没加await也没写.catch()处理rejection，JavaScript运行时（比如Node.js）会触发「未处理的Promise拒绝」错误，直接终止进程。这时候finally块里的await releaseResources()还没来得及执行，就导致资源释放代码跑不起来。
• 要是fn()的Promise一直处于pending状态，finally块的代码其实会执行，但withinScope的返回值会跟着pending，如果你没等待withinScope()完成就退出进程，同样会导致资源释放没做完。

第二种写法为什么能正常执行 #

const withinScope = async(fn)=>{
  try{
    const result = await fn()
    return result
  }finally{
    await releaseResources()
  }
}

这里用await fn()显式等待fn()的Promise完成：

• 不管fn()是成功resolve还是失败reject，await都会把结果或异常纳入try块的处理流程；
• 当fn()reject时，会直接触发try块的异常逻辑，跳去finally块执行releaseResources()，确保资源释放先完成，之后withinScope的Promise才会reject；
• 哪怕你没捕获rejection，资源释放操作也已经执行完毕，不会出现漏跑的情况。

简单说：第一种写法里资源释放没执行，是因为Promise的错误没被await接住，导致进程在finally的异步操作完成前就挂了，这是JS异步机制的预期行为，不是Bug。

内容的提问来源于stack exchange，提问作者caeus