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<string></string>❌ 避免
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 真的释放了线程吗？异常能被正确捕获吗？上层有没有在等它？
