为何微软源码中未使用async/await？相关技术疑问解答

先看HttpClient.PutAsync的实现代码：

public Task<HttpResponseMessage> PutAsync(Uri requestUri, HttpContent content,
    CancellationToken cancellationToken)
{
    HttpRequestMessage request = new HttpRequestMessage(HttpMethod.Put, requestUri);
    request.Content = content;
    return SendAsync(request, cancellationToken);
}

针对你提出的两个问题，解析如下：

1. 何种场景下可移除async/await关键字？ #

当方法满足以下全部条件时，完全可以省略async/await：

• 核心逻辑是直接返回一个已存在的Task对象，没有需要等待的其他异步操作
• 不需要在Task完成前后执行额外逻辑（比如捕获异常、修改返回值、清理资源、更新内部状态等）
• 不需要依赖async关键字的自动异常包装能力（即无需把同步异常自动封装进返回的Task中）

比如上面的PutAsync，仅创建请求对象后直接返回SendAsync的Task，无后续处理逻辑，因此可以安全省略async/await。反之，如果方法内包含await SomeOtherAsync();这类异步等待逻辑，或者需要在Task完成后处理结果（如var result = await task; return ProcessResult(result);），则必须保留async/await。

2. 省略async/await会对性能产生影响吗？ #

会有轻微但可衡量的性能提升：

• 使用async/await时，编译器会自动生成状态机类跟踪异步执行状态，这会带来额外的内存分配（状态机实例）与少量CPU开销
• 直接返回Task时，避免了状态机创建、上下文切换的额外处理，减少了不必要的性能损耗

这种差异在普通业务场景下可能不明显，但在高频调用的框架方法、高并发接口中，累计的性能收益会比较显著。不过需注意，不要为了这点性能牺牲代码可读性——后续若需添加异步逻辑，再补加async/await即可。

内容的提问来源于stack exchange，提问作者Farhad Zamani