https://blog.stephencleary.com/2016/12/eliding-async-await.html
当开发者掌握了 async 和 await 的基础知识并能熟练运用后，常会遇到一个设计疑问：如果可以移除 async 和 await 关键字，是否应该这样做？在很多场景下，确实可以省略这两个关键字，直接返回任务（task）。
这个问题的答案远比想象中复杂。事实上，我现在的观点与最初对此问题的立场已有所不同。
支持省略关键字的理由
效率优势
省略 async 和 await 能提升效率。不使用这两个关键字时，编译器无需生成 async 状态机。这意味着程序集中的编译器生成类型会减少，垃圾回收器的压力会减轻，需要执行的 CPU 指令也会变少。
但需要明确的是，这些性能提升都极其微小。仅会减少一个类型、节省少量小对象的垃圾回收开销，同时跳过少量 CPU 指令。绝大多数情况下，async 用于处理 I/O 操作，而 I/O 操作的耗时会完全掩盖这些性能提升。几乎在所有场景中，省略 async 和 await 都不会对应用程序的运行时间产生实质性影响。
若想全面了解省略 async 和 await 带来的效率优势，可参考 Stephen Toub 的经典视频《异步编程的禅道》（The Zen of Async）或他在 MSDN 上的相关文章。
我刚开始撰写关于 async 的内容时，总会建议省略 async 和 await，但近年来已调整了这一立场。省略关键字存在太多潜在陷阱，不应将其作为默认选择。如今，除少数特定场景外，我都建议保留 async 和 await 关键字——以下将详细说明其中的弊端。
潜在陷阱
省略 async 和 await 后，编译器不会对方法进行相关修改。但这也意味着，若想保持相同的语义，原本由编译器完成的工作都需要手动实现。
using 语句的问题
省略 async 和 await 时最常见的错误之一，是开发者忘记方法末尾有代码需要在合适的时机执行。尤其是在使用 using 语句的场景中：
public async Task<string> GetWithKeywordsAsync(string url)
{using (var client = new HttpClient())return await client.GetStringAsync(url);
}public Task<string> GetElidingKeywordsAsync(string url)
{using (var client = new HttpClient())return client.GetStringAsync(url);
}
在这个示例中，省略关键字会导致下载操作中止。
我们可以通过梳理代码执行流程来理解这一点（若需回顾相关知识，我撰写的 async 和 await 入门文章至今仍适用）。为简化说明，假设 HttpClient.GetStringAsync 永远不会同步完成。
对于 GetWithKeywordsAsync，代码执行流程如下：
- 创建
HttpClient对象。 - 调用
GetStringAsync，返回一个未完成的任务。 - 暂停方法执行，直到
GetStringAsync返回的任务完成，并返回一个未完成的任务。 - 当
GetStringAsync返回的任务完成后，恢复方法执行。 - 释放
HttpClient对象。 - 完成
GetWithKeywordsAsync之前返回的任务。
对于 GetElidingKeywordsAsync，代码执行流程如下：
- 创建
HttpClient对象。 - 调用
GetStringAsync，返回一个未完成的任务。 - 释放
HttpClient对象。 - 返回
GetStringAsync生成的任务。
显然，HttpClient 在 GET 任务完成前就被释放了，这会导致请求被取消。正确的做法是（异步）等待 GET 操作完成后，再释放 HttpClient——而使用 async 和 await 恰好能实现这一逻辑。
异常处理的差异
另一个容易被忽略的陷阱与异常相关。async 方法的状态机会捕获代码中的异常，并将其封装到返回的任务中。若没有 async 关键字，异常会直接抛出，而非被封装到任务里：
public async Task<string> GetWithKeywordsAsync()
{string url = /* 可能抛出异常的逻辑 */;return await DownloadStringAsync(url);
}public Task<string> GetElidingKeywordsAsync()
{string url = /* 可能抛出异常的逻辑 */;return DownloadStringAsync(url);
}
只要调用方采用以下方式调用，这两个方法的行为完全一致：
var result = await GetWithKeywordsAsync(); // 正常工作
var result = await GetElidingKeywordsAsync(); // 正常工作
但如果方法调用与 await 操作分离，两者的语义就会出现差异：
var task = GetWithKeywordsAsync();
var result = await task; // 异常在此处抛出var task = GetElidingKeywordsAsync(); // 异常在此处抛出
var result = await task;
方法调用与 await 分离的场景有很多。例如，调用方可能在执行异步操作的同时，还需要处理其他工作——这种情况在使用 Task.WhenAll 的代码中最为常见。
异步编程的预期语义是，异常应被封装到返回的任务中。因为返回的任务代表了方法的执行过程，若方法执行因异常终止，最自然的表现形式就是一个出错的任务（faulted task）。
因此，在这种场景下省略关键字，会导致异常行为与预期不符。
AsyncLocal 的上下文问题
这个陷阱的逻辑相对复杂。
AsyncLocal<T>（以及更低层级的 LogicalCallContext）允许异步代码使用一种与 async 兼容的、类似线程本地存储（thread local storage）的机制。其工作原理是，在 async 编译器转换过程中，编译器生成的代码会通知逻辑调用上下文（logical call context），建立一个写时复制（copy-on-write）作用域。
这一机制能让上下文信息在异步调用中“向下”传递，但需要注意的是，值不会“向上”传递。
static AsyncLocal<int> context = new AsyncLocal<int>();static async Task MainAsync()
{context.Value = 1;Console.WriteLine("Should be 1: " + context.Value);await Async();Console.WriteLine("Should be 1: " + context.Value);
}static async Task Async()
{Console.WriteLine("Should be 1: " + context.Value);context.Value = 2;Console.WriteLine("Should be 2: " + context.Value);await Task.Yield();Console.WriteLine("Should be 2: " + context.Value);
}
在上述示例中，子方法 Async 中修改了上下文值，但当 Async 完成且控制流回到 MainAsync 后，代码会在“父”上下文环境中执行。因此，“父”上下文的值会传递到“子”上下文，但“子”上下文修改后的值不会传递回“父”上下文。
需要注意的是，同步方法不会通知逻辑调用上下文发生了变化。对于普通的（非返回任务的）同步方法，这不会有问题——从逻辑调用上下文的角度来看，所有同步调用都会被“合并”，它们实际上属于调用栈中最近的上层 async 方法的上下文。例如：
static AsyncLocal<int> context = new AsyncLocal<int>();static async Task MainAsync()
{context.Value = 1;Console.WriteLine("Should be 1: " + context.Value);await Async();Console.WriteLine("Should be 1: " + context.Value);
}static async Task Async()
{Console.WriteLine("Should be 1: " + context.Value);Sync();Console.WriteLine("Should be 2: " + context.Value);await Task.Yield();Console.WriteLine("Should be 2: " + context.Value);
}static void Sync()
{Console.WriteLine("Should be 1: " + context.Value);context.Value = 2;Console.WriteLine("Should be 2: " + context.Value);
}
在这个示例中，Async 方法能感知到其子方法 Sync 对上下文的修改。如前所述，我更倾向于将同步方法理解为上层最近的 async 上下文的一部分——从上下文角度来看，Sync 只是 Async 的一部分。
而当省略 async 和 await 时，返回任务的非 async 方法会被上下文视为普通同步方法。因此，若该方法修改了逻辑调用上下文，实际上会影响其上层上下文：
static AsyncLocal<int> context = new AsyncLocal<int>();static async Task MainAsync()
{context.Value = 1;Console.WriteLine("Should be 1: " + context.Value);await Async();Console.WriteLine("Should be 1: " + context.Value); // 实际输出为 "2"——与预期不符！
}static Task Async()
{Console.WriteLine("Should be 1: " + context.Value);context.Value = 2;Console.WriteLine("Should be 2: " + context.Value);return Task.CompletedTask;
}
这种场景并不常见，但确实是省略 async/await 可能引发的陷阱之一。
推荐指南
我建议遵循以下准则：
- 默认不省略关键字。使用
async和await能让代码更自然、更易读。 - 当方法仅作为透传（passthrough）或重载时，可考虑省略关键字。
示例：
// 简单透传到下一层：省略关键字
Task<string> PassthroughAsync(int x) => _service.PassthroughAsync(x);// 方法的简单重载：省略关键字
async Task<string> OverloadsAsync(CancellationToken cancellationToken)
{... // 核心实现，使用 await
}
Task<string> OverloadsAsync() => OverloadsAsync(CancellationToken.None);// 非简单透传：使用关键字
async Task<string> PassthroughAsync(int x)
{// 原因：GetFirstArgument 可能抛出异常// 即使现在不抛异常，后续也可能有人修改它，且未必会同步修改此方法return await _service.PassthroughAsync(GetFirstArgument(), x);
}// 非简单方法重载：使用关键字
async Task<string> OverloadsAsync()
{// 原因同上：GetDefaultCancellationTokenForThisScope 可能抛出异常return await OverloadsAsync(GetDefaultCancellationTokenForThisScope());
}
