在 async 函数中，finally 块内使用 await 不会自动阻塞 Promise 的返回或错误传播；若在 catch 中提前调用 reject()，后续 finally 中的 await 将失去上下文，导致清理逻辑被忽略或未等待即退出。
在 async 函数中，`finally` 块内使用 `await` 不会自动阻塞 promise 的返回或错误传播；若在 `catch` 中提前调用 `reject()`，后续 `finally` 中的 `await` 将失去上下文，导致清理逻辑被忽略或未等待即退出。
你遇到的问题本质是控制流与 Promise 生命周期的错配：原始代码中，reject(err) 立即触发了外部 Promise 的拒绝状态，而 finally 块中的 await cleanup() 虽然执行了，但它所依赖的 .then(() => resolve('done')) 是在 reject() 之后才尝试 resolve —— 此时 Promise 已处于 rejected 状态，再次 resolve 无效（且 Node.js 会静默忽略），同时主流程不会等待该异步清理完成便直接抛出未捕获异常。
✅ 正确做法是：将整个 try/catch/finally 逻辑封装在一个 async 函数中，并返回一个统一的 Promise，确保所有异步清理都参与控制流。finally 中的 await 只有在该 async 函数自身返回的 Promise 被等待时，才能真正“生效”。
以下是修复后的可运行示例：
async function runWithCleanup() {
let cleanup = () => {
console.log('inside cleanup');
return new Promise(resolve => setTimeout(resolve, 5000));
};
try {
throw new Error('error');
} catch (err) {
console.log('caught error:', err.message);
// 不在此处 reject —— 让错误继续向上冒泡，但先完成清理
} finally {
console.log('inside finally');
await cleanup(); // ✅ 这里的 await 会真正暂停函数执行，直到 cleanup 完成
console.log('cleanup done, exiting');
}
return 'done'; // 成功路径返回值
}
// 正确使用方式：等待整个 async 函数完成
runWithCleanup()
.then(result => console.log('resolved:', result))
.catch(err => console.log('finally rejected:', err.message));
? 关键要点：
-
await在finally中语法合法且有效，但它只影响其所在async函数的执行顺序，不改变外部 Promise 的状态决定时机； - 若需“错误发生后仍保证异步清理完成”，应避免在
catch中立即reject()，而是让错误自然传播，并在finally中await清理，最后统一return或throw； - 多步骤有序清理？只需链式
await：finally { await cleanupDB(); await cleanupCache(); await cleanupNetwork(); console.log('all resources released'); } - ⚠️ 注意：Node.js finally 中
await的支持已完备，但若目标环境较老，建议包裹在try { ... } finally { await Promise.all([...]) }中以兼容。
总结：finally 中的 await 不是“魔法钩子”，它只是 async 函数语法糖的一部分；要让异步清理真正被等待，必须确保该 await 所在的 async 函数本身被 await 或 .then() 链正确消费——清理逻辑应成为 Promise 链的必要环节，而非旁路回调。
