在 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 的拒绝，而后续 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 风格，既能保障清理执行，又能清晰表达控制流与错误传播逻辑。
