17370845950

async/await 是协作式异步模型，用于不阻塞线程、提升响应性；只对真正异步的 I/O 操作使用，避免滥用在 CPU 密集型或同步代码上，注意返回类型、禁止 async void（除事件处理器）、禁用 .Result/.Wait() 防死锁，并合理处理并发与异常。

async/await 不是“让方法变快”的魔法开关，而是用来不阻塞线程、提升响应性和资源利用率的协作式异步模型。正确使用的关键在于理解“什么该异步”“谁在等待”“线程上下文怎么流转”。

只对真正异步的操作用 async/await

不是所有耗时操作都适合加 async。CPU 密集型任务（比如大数组排序、图像处理）用 Task.Run() 搬到线程池即可，不要盲目套 await；而 I/O 类操作（HTTP 请求、文件读写、数据库查询）天然支持异步，应优先使用它们的 Async 版本（如 HttpClient.GetAsync()、FileStream.ReadAsync()）。

• ✅ 正确：调用 await httpClient.GetStringAsync(url)
• ❌ 错误：给普通 for 循环包一层 async Task 还 await 它
• ⚠️ 谨慎：CPU 工作用 await Task.Run(() => HeavyCalc())，但要评估是否真有必要——可能直接同步执行更高效

async 方法必须有 await，且返回 Task 或 Task

标记为 async 的方法，编译器会重写为状态机。如果里面没写 await，不仅失去异步意义，还会产生不必要的开销（装箱、状态机分配）。返回类型也必须匹配：

• 无返回值 → async Task（不是 void，除非是事件处理器）
• 有返回值 → async Task
• ❌ 避免 async void（除 UI 事件），它无法被 await、异常会直接崩掉线程

避免 .Result 和 .Wait()，防止死锁

在有同步上下文的环境（如 WinForms/WPF 主线程、ASP.NET 同步上下文旧版本），直接调用 task.Result 或 task.Wait() 极易引发死锁——因为 await 默认会尝试回到原上下文，而主线程正卡在等结果。

• ✅ 始终用 await task
• ✅ 如果真要同步等待（极少见），用 task.ConfigureAwait(false).GetAwaiter().GetResult() 放弃上下文捕获
• ❌ 不要混用：在 async 方法里又用 .Result

合理控制并发和异常处理

异步不是“放任不管”。多个异步操作并行时，注意资源竞争和异常聚合：

• 并发请求用 Task.WhenAll(tasks)，别用循环 await（那是串行）
• 异常会被包装进 AggregateException，建议用 try/catch 包住 await 表达式，直接捕获业务异常
• 需要取消时，传入 CancellationToken 并在 async 方法中适时检查或传给底层 API（如 HttpClient.GetAsync(url, token)）

基本上就这些。async/await 本身不复杂，但容易忽略上下文、错误类型和调用链一致性。写完多问一句：这个 await 真的释放了线程吗？异常能被正确捕获吗？上层有没有在等它？