在C#中处理文件读写、数据库访问或HTTP请求时，同步方法会让当前线程一直等待操作完成，期间无法处理其他任务。对于桌面应用程序，这意味着界面失去响应；对于服务端程序，这意味着线程池资源被大量消耗。async和await关键字自C# 5.0引入后，让开发者能够用接近同步代码的结构实现异步执行：方法在遇到await时立即返回调用方，等待操作完成后再从暂停位置继续运行。这种模式不依赖开发者手动管理回调或任务延续，显著降低了异步编程的复杂度。
异步编程要解决的核心问题
同步I/O操作最直接的后果是线程阻塞。在Windows Forms或WPF应用中，UI线程负责消息循环和控件重绘，如果在一个按钮事件里执行了同步数据库查询，整个界面会停住，用户点击任何位置都不会有反应，直到查询结束。使用异步方式后，UI线程在等待查询结果时可以继续响应其他输入，体验明显改善。
服务端程序面临的问题更隐蔽。ASP.NET Core的线程池线程数量有限，每个请求通常会分配一个线程来处理。同步I/O会导致线程在等待磁盘或网络数据期间处于空闲占用状态，新的请求不得不排队或创建额外线程。线程创建和上下文切换都有成本，最终表现为吞吐量下降和延迟升高。async和await可以让线程在等待I/O时返回线程池处理其他请求，I/O完成后由系统通知恢复执行，从而用更少的线程支撑更高的并发。
需要注意的是，异步并不等同于多线程。异步I/O借助操作系统底层完成端口或事件通知，等待期间不需要占用任何托管线程；而多线程是通过创建额外的线程并行执行代码。对于CPU密集型的计算，await帮不上忙，需要借助Task.Run把工作分配到线程池，但那是另一个话题。理解这一点有助于避免为了异步而异步的滥用。
async和await如何工作
async关键字用来标记一个方法，表明该方法内部至少有一个await表达式，并且编译器会为这个方法生成异步状态机。这样的方法返回值通常是Task、Task<T>或ValueTask，表示异步操作的进度和结果。调用async方法时，方法体会同步执行到第一个await表达式之前，然后返回一个未完成的Task给调用者。await关键字则告诉编译器：等待右侧的Task完成，如果尚未完成，就挂起当前方法并释放线程，完成后再从挂起点继续执行。
下面是一个简单的异步HTTP请求方法：
public async Task<string> DownloadContentAsync(string url)
{
using var client = new HttpClient();
// 执行到await时，当前线程被释放，GetStringAsync完成后恢复
string content = await client.GetStringAsync(url);
return content;
}
调用方可以这样使用：
public async Task ProcessAsync()
{
string html = await DownloadContentAsync("https://ipipp.com");
Console.WriteLine(html.Length);
}
当ProcessAsync执行到await DownloadContentAsync时，会调用DownloadContentAsync。DownloadContentAsync内部在await GetStringAsync处返回一个未完成的Task。ProcessAsync的await检测到Task未完成，也会挂起并返回一个Task给它的调用者。这样层层返回，最终将控制权交回线程池。一旦HTTP响应到达，GetStringAsync对应的任务完成，状态机恢复DownloadContentAsync的后续代码，返回字符串；随后ProcessAsync的等待也完成，继续执行Console.WriteLine。整个过程没有线程被阻塞。
编译器生成的状态机保存了局部变量、参数和下一个要执行的状态编号。对于简单方法，这种开销很小；对于高频调用的轻量方法，可以考虑直接返回Task而不是加上async和await，因为少了一层状态机分配。返回值类型方面，Task用于没有结果的操作，Task<T>用于返回结果，ValueTask可以在已知任务经常已完成同步时减少堆分配。
常见误区和性能陷阱
第一个常见误区是使用async void。除了事件处理器和少数特殊回调外，异步方法应该返回Task。async void方法无法被等待，调用者不知道它何时完成；如果内部抛出异常，异常会直接抛到同步上下文，甚至可能导致进程崩溃。因此普通业务方法前缀async时，返回值要么是Task要么是Task<T>。
第二个常见问题是同步等待异步任务。比如在代码中写Task.Wait()或者Task.Result来获取异步结果。在UI线程或旧的ASP.NET环境中，await默认会尝试捕获当前同步上下文，并在任务完成后回到该上下文继续执行。如果UI线程被Wait阻塞，任务永远无法回到UI线程，形成死锁。解决方式是在可能被同步等待的库代码中使用ConfigureAwait(false)，让后续代码不回到原上下文。虽然.NET Core和较新的ASP.NET Core不再有单一的SynchronizationContext，死锁风险降低，但库代码中依然建议使用ConfigureAwait(false)来避免无谓的上下文捕获。
第三个误区是过度使用async。如果一个方法内部只有返回另一个Task，并且没有额外的await处理，那么直接返回该Task即可，不要添加async和await，否则会多生成一个状态机和额外的任务包装。例如：
// 不推荐：不必要的async/await
public async Task<string> GetDataAsync()
{
return await client.GetStringAsync("https://ipipp.com");
}
// 推荐：直接返回Task
public Task<string> GetDataAsync()
{
return client.GetStringAsync("https://ipipp.com");
}
这种写法不仅少一层状态机，还能减少一次Task分配，提升高频路径上的性能。
异常处理与任务取消
使用await的异步方法可以像同步代码一样使用try-catch捕获异常。如果await的任务内部抛出异常，await表达式会重新抛出该异常，直接进入catch块，不需要检查Task.Status或调用Task.Exception。但当多个任务通过Task.WhenAll等待时，如果多个任务都失败，WhenAll返回的Task会包含一个AggregateException，其中InnerExceptions属性包含所有任务的异常。此时可以遍历或使用Flatten方法处理。
取消操作通过CancellationToken传递。很多异步API都有接受CancellationToken的重载，例如HttpClient.GetStringAsync。调用方创建CancellationTokenSource，并在需要时调用Cancel方法。被调用方可以通过token.ThrowIfCancellationRequested()主动检查取消信号。示例：
public async Task ProcessWithCancellationAsync(CancellationToken token)
{
using var client = new HttpClient();
// 传入token，请求可被取消
string content = await client.GetStringAsync("https://ipipp.com", token);
token.ThrowIfCancellationRequested();
Console.WriteLine(content.Length);
}
调用方可以设置超时：
using var cts = new CancellationTokenSource(TimeSpan.FromSeconds(5));
try
{
await ProcessWithCancellationAsync(cts.Token);
}
catch (OperationCanceledException)
{
Console.WriteLine("操作已取消或超时");
}
需要注意，取消是一种协作机制，如果被调用的API不检查token，调用Cancel也不会立即中止操作。对于自定义的CPU密集循环，应在每次迭代中检查token并抛出异常。
编写可维护异步代码的建议
命名约定上，异步方法一般以Async结尾，例如DownloadContentAsync、SaveAsync。这样调用者可以一眼识别出方法返回Task，并且需要await。公共接口和基类中的异步方法也应该遵循这一约定，避免使用者误以为可以同步调用。很多静态分析工具会检查这一规则。
在库代码中，尽量使用ConfigureAwait(false)。这避免了在每次await时捕获并提交回原同步上下文，减少不必要的调度，同时降低了在特定宿主中死锁的概率。应用程序代码如果需要更新UI，则不能使用ConfigureAwait(false)，因为更新控件必须在UI线程上执行。
对于返回集合的异步方法，C# 8.0引入的IAsyncEnumerable<T>配合await foreach可以按批次消费数据，避免一次性加载全部结果。对于需要异步释放的资源，可以实现IAsyncDisposable并使用await using。这些特性让异步编程从单个操作扩展到流式场景，写出更高效且资源友好的代码。
最后，异步代码的可测试性比回调式代码更好。单元测试中可以直接await方法并断言异常，配合Task.FromResult、Task.CompletedTask等辅助方法模拟已完成的任务。保持每个异步方法职责单一，避免在异步方法内混合过多的同步阻塞操作，是长期可维护性的关键。