异步方法代理任务时省略async/await的合理性咨询

我之前一直遵循“异步方法通常应使用async/await”的实践，最近看到一篇文章提到，在代理任务的场景下无需使用async关键字，比如：

// Simple passthrough to next layer: elide.
Task<string> PassthroughAsync(int x) => _service.DoSomethingPrettyAsync(x);

// Simple overloads for a method: elide.
async Task<string> DoSomethingPrettyAsync(CancellationToken cancellationToken)
{
    ... // Core implementation, using await.
}

我有两个疑问：为什么这种场景下不需要async/await？这样做是否不够便捷，是否具备合理性？

核心原因：减少冗余的状态机开销 #

当你给方法加上async关键字时，编译器会自动生成一个状态机来管理异步流程——包括捕获当前同步上下文、跟踪await的完成状态、处理异常包装等。但在纯任务代理的场景下，你的方法只是把下层返回的Task直接传递出去，没有任何额外的异步逻辑需要处理，这时候生成的状态机完全是多余的，会带来不必要的性能开销（虽然单看一次调用影响很小，但在高频调用的场景下，累积起来的开销会变得明显）。

直接返回Task的方式，就跳过了这个状态机的生成，让代码更高效。

合理性与便捷性分析 #

这种做法不仅合理，反而在很多情况下更便捷：

1. 语义更清晰：直接返回Task的写法，一眼就能让阅读代码的人明白——这个方法只是“传递任务”，没有额外的业务逻辑或异步操作，代码意图非常明确。
2. 代码更简洁：省去了async和await关键字，减少了不必要的代码行数，让方法的核心逻辑（代理任务）更加突出。
3. 异常处理一致：可能有人担心直接返回Task会影响异常处理，但实际上，下层任务抛出的异常会被包含在返回的Task中，调用者在await这个Task时，依然能正常捕获到异常，和使用async/await的行为完全一致。

什么时候不能省略？ #

当然，这种写法只适用于纯代理任务的场景。如果你的方法需要在代理前后添加额外逻辑（比如日志记录、参数校验、结果转换、异常捕获处理等），就必须使用async/await，比如：

async Task<string> PassthroughWithLoggingAsync(int x)
{
    _logger.LogDebug("Forwarding request to service");
    var result = await _service.DoSomethingPrettyAsync(x);
    _logger.LogDebug("Received result: {Result}", result);
    return result;
}

这种情况下，await是必须的——你需要等待下层任务完成后，才能执行后续的逻辑。

总结 #

在纯任务代理的场景下省略async/await是一种被广泛认可的最佳实践，它既提升了代码的执行效率，又让代码更简洁、语义更明确。只要确认你的方法没有额外的异步逻辑需要处理，就可以放心使用这种写法。

内容的提问来源于stack exchange，提问作者Roelant M