异步流程中try-catch-finally不会自动等待异步操作，必须await才能正确捕获异常并确保finally在所有异步任务结束后执行；finally内可await但会覆盖原异常。
在异步流程中，try-catch-finally 的执行逻辑与同步代码有本质区别：它**不会自动等待异步操作完成**，除非你显式使用 await。直接把 async 函数写进 try 块里，但不 await，finally 会立刻执行，而异步任务还在后台跑——这极易导致资源泄漏或逻辑错乱。
异步函数必须 await 才能被正确捕获
如果只调用一个 async 函数却不 await，它返回的是一个 Promise（或 Task），try 块认为“执行完了”，随即进入 finally，而异步操作可能刚起步甚至还没开始。
- ✅ 正确写法：
await fetchData()—— 异常会在catch中被捕获，finally在整个异步流程结束后执行 - ❌ 错误写法：
fetchData()（无 await）——try立即结束，finally马上运行，异常若发生在后续 Promise 中，将无法被当前catch捕获
多个 await 时，finally 仍只执行一次，但时机由最后一个 await 决定
只要所有 await 都在 try 块内，无论中间有多少次异步等待，finally 总是在整个 try 块的控制流真正退出时执行（成功、抛错、或被 return 中断）。
- 若第 1 个
await失败，catch处理后，仍会执行finally - 若
try中有return await something()，先保存返回值 → 执行finally→ 再真正返回 -
finally内部也支持await，但需注意：它本身不能被外部catch捕获其内部抛出的新异常
finally 中的 await 不会阻塞返回，但会影响清理时机
现代语言（如 C# 8+、TypeScript/ES2022+）允许 finally 块内使用 await，前提是整个函数是 async 的。此时 finally 的异步操作会真实等待完成，确保资源释放不被跳过。
- 例如：关闭数据库连接、清除临时文件、取消未完成请求 —— 这些都应
await完成后再让函数彻底退出 - ⚠️ 注意：
finally中若抛出新异常，会覆盖原异常（或 return 值），且上层只能捕获这个新异常
常见陷阱与规避建议
很多问题源于对“执行完成”的误解。异步不是“多线程并行”，而是“控制流暂停等待”。try-catch-finally 的结构只管同步控制流，不管异步任务生命周期。
- 不要在
try中漏掉await，尤其在循环或条件分支里 - 避免在
finally中做耗时长但非关键的异步操作（如日志上报），可改用fire-and-forget或单独处理 - 需要保证清理一定发生？优先用
using（C#）或try...finally+await显式清理，别依赖 Promise 的.finally()（那是 Promise 方法，和语法块无关） - 调试时打印日志，确认
finally是在所有await结束后才进入，而不是一进try就触发
