catch 块中不能直接 await，会编译报错
在 C# 中，
catch和
finally块本身不支持异步上下文，所以直接写
await会导致编译错误 CS1942：“表达式树中不允许使用 await”。这不是运行时限制，而是语法层面禁止——因为
catch/
finally属于同步异常处理结构，CLR 要求它们必须以同步方式完成。
常见错误写法：
try
{
await DoSomethingAsync();
}
catch (Exception ex)
{
await LogErrorAsync(ex); // ❌ 编译失败
}用 async void 或单独启动 Task 来绕过？别这么做
有人尝试把
catch里的逻辑包进
async void或
Task.Run，这是危险的：
async void无法被等待，异常会直接抛到 SynchronizationContext（可能崩掉整个应用）
Task.Run(() => LogErrorAsync(ex))会脱离当前上下文，且无法感知是否执行成功，也丢失了异常传播链 如果日志服务本身有重试或超时逻辑，这种“发完就丢”的方式会让故障排查变得困难
真正可行的做法是：把需要异步处理的逻辑提前或延后——要么在
try块里预判并捕获，要么把整个 try-catch 包进一个
async方法中，再用同步方式“暂存”异常，之后再
await。
推荐方案：在 async 方法中用局部变量保存异常，离开 catch 后 await
核心思路是避免在
catch块内调用
await，而是记录异常对象，等跳出异常处理结构后再异步处理：
public async Task ProcessAsync()
{
Exception caughtEx = null;
try
{
await DoSomethingAsync();
}
catch (Exception ex)
{
caughtEx = ex; // ✅ 只做赋值，不 await
}
<pre class='brush:php;toolbar:false;'>if (caughtEx != null)
{
await LogErrorAsync(caughtEx); // ✅ 在普通代码路径中 await
throw caughtEx; // 根据业务决定是否重新抛出
}}
这个模式安全、可控，且保留了完整的调用栈。注意两点：
不要用ex.ToString()或序列化后的字符串代替原始
Exception对象，否则会丢失
StackTrace、
InnerException等关键诊断信息 如果
LogErrorAsync是关键路径（比如审计日志），建议加超时和降级逻辑，防止它拖垮主流程
finally 块中 await 的替代方案：用 using + IAsyncDisposable
C# 8+ 支持
IAsyncDisposable，配合
await using可以在资源释放阶段自然支持异步清理：
public class AsyncResource : IAsyncDisposable
{
public async ValueTask DisposeAsync()
{
await CleanupAsync(); // ✅ 这里可以 await
}
}
<p>// 使用方式：
await using var resource = new AsyncResource();
await DoWorkAsync(); // 正常逻辑这比手动在
finally里模拟异步清理更可靠。如果你控制不了资源类型（比如第三方库返回的
IDisposable），那就只能把清理逻辑移到方法末尾，用
try/finally+ 标志位来协调：
bool completed = false;
try
{
await DoSomethingAsync();
completed = true;
}
finally
{
if (!completed)
{
// 这里只能同步清理；异步部分仍需延迟到方法尾部
await CleanupAfterFailureAsync(); // ✅ 放在 finally 外面
}
}真正难处理的不是语法限制，而是把“异常发生时必须异步响应”这个需求，误当成必须在
catch块里完成。其实绝大多数场景下，只要保证异常对象不丢失、响应不遗漏、上下文不污染，延迟几十毫秒再
await并不影响语义正确性。
