如何在 async 函数的 finally 块中正确等待异步清理操作

在 async 函数中，直接在 finally 块内使用 await 不会阻塞 Promise 的拒绝/解决流程；若未妥善协调 try/catch/reject/resolve 的时序，清理逻辑将被忽略或导致未处理异常。

在 async 函数中，直接在 finally 块内使用 await 不会阻塞 Promise 的拒绝/解决流程；若未妥善协调 try/catch/reject/resolve 的时序，清理逻辑将被忽略或导致未处理异常。

这个问题说到底，卡在控制流和 Promise 生命周期没有对齐上：finally 里的 await cleanup() 的确会让 async IIFE 先停一下，等清理逻辑跑完再继续；但问题在于，reject(err) 早就把外部 Promise 提前置为了 rejected，后面的 resolve('done') 又试图再次去结束这个已经拒绝过的 Promise。这样做本身就是无效的，而且还踩中了 Promise 状态不可逆这条基本规则——也就是从 pending 进入 fulfilled 或 rejected 之后，就不能再改了——于是就很容易抛出“Cannot resolve or reject a settled promise”这类错误。在 Node.js 里，这类情况通常会表现为未捕获的 rejection，严重时甚至会直接导致进程异常退出。

问题的症结其实就在这里：async 函数里的 await，影响的只是这个函数内部的执行节奏，并不会顺带帮你协调外层 Promise 构造器里 resolve/reject 的触发时机。放到这段代码里看，reject(err) 在 finally 真正跑完之前就已经先一步执行了，所以外层 Promise 会立刻进入 rejected 状态；到了这一步，哪怕 finally 里的 await cleanup() 还在继续执行，后面的 resolve('done') 也已经无力回天，根本改不了这个 Promise 的最终状态。

✅ 正确做法：将整个异步逻辑封装在 async 函数中，并统一通过 return 或顶层 await 控制最终结果，避免手动调用 resolve/reject：

const run = (async () => {
const cleanup = () => {
console.log('inside cleanup');
return new Promise(resolve => 
setTimeout(() => {
console.log('cleanup completed');
resolve();
}, 5000)
);
};

try {
throw new Error('error');
} catch (err) {
console.log('caught error:', err.message);
// 不在此处 reject —— 让 finally 决定最终结果
} finally {
console.log('inside finally');
await cleanup(); // ✅ 真正等待清理完成
console.log('exiting');
return 'done'; // ✅ 最终返回值将成为 Promise 的 fulfillment value
}
})();

run.then(result => console.log('success:', result))
 .catch(err => console.error('failed:', err));

? 注意事项：

• 永远不要在 async 函数中混用 Promise 构造器回调（resolve/reject）与 await：二者属于不同抽象层级，易引发状态冲突；
• finally 中的 await 是合法且有效的，但前提是它属于一个被 await 或 .then() 链式消费的 Promise —— 即 async 函数本身需作为 Promise 被正确使用；
• 若需按序清理多个资源，可链式 await 或使用 for...of + await：

  finally {
  for (const resource of [db, cache, fileHandle]) {
  await resource.close(); // 顺序执行，前一个完成才开始下一个
  }
  }

• 如需在出错时仍保证清理并保留原始错误，可捕获后重新抛出：

  } catch (err) {
  await cleanup();
  throw err; // 清理后重抛，确保错误不被吞没
  }

总结：await 在 finally 中完全可用，但必须置于由 async 函数返回的 Promise 上下文中，而非嵌套在手动构造的 Promise 回调里。重构为纯 async/await 风格，既能保障清理执行，又能清晰表达控制流与错误传播逻辑。