c#如何使用async和await_c#async和await从入门到精通教程-C#.Net教程-PHP中文网

async/await 是编译器生成状态机以简化异步i/o的同步风格写法，非多线程；必须返回task/task，避免async void（仅限事件处理器）；await对象需支持getawaiter()；库中每个await都应配configureawait(false)。

c#如何使用async和await_c#async和await从入门到精通教程

async/await 不是多线程，也不是“让代码变快”的银弹；它本质是编译器帮你重写状态机，用来简化异步 I/O 操作的线性表达——用同步风格写异步逻辑，但阻塞的是逻辑流，不是线程。

这是最常踩的坑：把普通方法加个 async 就以为能 await，结果编译报错或行为异常。

async void 无法被等待、无法捕获异常（异常会直接抛到 SynchronizationContext，可能崩掉 UI 线程）
后台任务、命令行入口、Web API 控制器方法，一律用 async Task 或 async Task<t></t>
WinForms/WPF 的按钮点击事件可以是 async void，仅因事件签名强制要求；但内部仍应尽快转为 await 一个 Task，别在 void 方法里写复杂异步链

比如你写了 var t = SomeAsyncMethod()，然后想在后面某个分支才 await t——这没问题；但如果你误把 Task.Run(() => {...}) 当作“启动后台线程”来用，就容易混淆用途。

"避开 C# 常见错误——空陷阱、异步陷阱、LINQ 陷阱及资源泄漏。"

下载

Task.Run 是 CPU 密集型操作的包装，会抢占线程池线程；I/O 操作（如 HttpClient.GetAsync、FileStream.ReadAsync）本身不占线程，用 Task.Run 包一层反而降低性能
await 的对象必须有 GetAwaiter() 方法且返回实现了 INotifyCompletion 的类型；自定义类型要实现 GetAwaiter 才能被 await
不要 await Task.Delay(1000).ConfigureAwait(false) 这样链式调用——ConfigureAwait 是对 Task 实例调用的，不是对 await 表达式本身

在类库（.NET Standard / .NET Core 类库）中，不加 ConfigureAwait(false) 可能导致死锁或上下文切换开销——尤其当调用方是 UI 线程或 ASP.NET 同步上下文时。

ASP.NET Core 默认无 SynchronizationContext，所以影响小；但 ASP.NET Framework（.NET 4.x）和 WinForms/WPF 有，不配置就可能卡死
规则很简单：只要你的方法不依赖 SynchronizationContext（比如不更新 UI 控件、不访问 HttpContext.Current），就在每个 await 后加 .ConfigureAwait(false)
不是“整个方法开头配一次”，而是每个 await 表达式都要配：await http.GetAsync(url).ConfigureAwait(false)

真正难的不是语法，是判断哪段该异步、哪段不该——比如数据库查询用 ExecuteReaderAsync，但后续的 List.Find 或 JSON 序列化是纯内存操作，不该套 Task.Run。async/await 的边界，永远由 I/O 和 CPU 划分，不是由“看起来慢”决定。