async 方法里 try-finally 能否保证 finally 执行？
能，但前提是
await的任务最终完成（无论成功、失败或被取消）。只要
await表达式所在的
async方法没有被线程中止（这在 .NET 中几乎不可能发生），
finally块一定会执行——哪怕
await后抛出异常、或任务被
CancellationToken取消触发
OperationCanceledException。
常见误解是“await 会跳出方法，finally 就不走了”，其实编译器把
async方法重写为状态机，
try-finally被拆解为状态迁移逻辑，
finally对应的清理代码会被注册为延续（continuation），由
Task完成时调度执行。
高并发下 finally 块可能被延迟执行吗？
不会延迟执行逻辑本身，但执行时机受
TaskScheduler和同步上下文影响。在 ASP.NET Core 默认无同步上下文环境下，
finally通常在
ThreadPool线程上立即回调；若在 WinForms/WPF 中使用
await且未加
.ConfigureAwait(false)，
finally会排队到 UI 线程，可能因消息队列积压而感知到延迟。 高并发本身不导致
finally延迟，但大量未完成的
Task会增加调度开销 若
finally里做了同步 I/O（如
File.WriteAllText）或长时间 CPU 计算，会阻塞当前线程，影响吞吐 不要在
finally中
await—— 编译器会报错：
CS4032: 'await' cannot be used in a 'finally' clause
资源释放场景：IDisposable 对象在 async 方法中怎么安全处置？
IDisposable实例不能靠
using（它只支持同步 dispose），必须显式在
finally中调用
Dispose()。若对象本身支持异步释放（如
IAsyncDisposable），则需另作处理——
finally无法
await，所以不能直接调用
DisposeAsync()。
典型做法是：对纯同步资源（如
MemoryStream、自定义锁对象）用
try-finally + Dispose()；对真正需要异步释放的资源（如数据库连接池中的连接），应避免在
finally中处理，改用
await using（C# 8+）并确保整个方法是
async：
public async Task ProcessDataAsync()
{
await using var conn = new SqlConnection(_connStr);
await conn.OpenAsync();
// ... do work
} // DisposeAsync() 在此处自动 await如果必须混合同步/异步资源，建议拆分逻辑：同步资源用
try-finally，异步资源用
await using或手动
try-catch-await处理
DisposeAsync()。
容易踩的坑：Cancellation 和 finally 的交互
当
await的任务因取消而抛出
OperationCanceledException，
finally仍会执行——这是正确行为。但开发者常误以为“取消 = 跳过清理”，结果导致资源泄漏。
另一个陷阱是：在
catch中重新抛出异常后，
finally仍执行；但如果在
catch中调用了
Environment.FailFast()或触发了堆栈溢出等不可恢复错误，
finally就不会运行——不过这种场景在高并发服务中极少见，也不该主动引入。
关键检查点：
确认所有await调用都传入了同一
CancellationToken，避免部分操作未响应取消导致
finally长时间挂起 不要在
finally中 throw 新异常——它会覆盖原始异常，掩盖根因 若
finally中调用的方法可能抛异常（如
stream.Dispose()在网络流已断开时），应额外包一层
try-catch并记录日志，防止压制上游错误
高并发下最易被忽略的是：
finally里的代码不是“原子”的——它可能被其他并发请求的相同逻辑交叉执行，所以涉及共享状态（如静态计数器、日志缓冲区）时，必须加锁或用线程安全类型（如
Interlocked、
ConcurrentQueue）。
