C#异步方法中await的放置：两种写法的性能差异探讨

首先明确结论：这两个方法的实际性能几乎没有差异，且都会同步阻塞调用线程——因为核心的耗时操作SynchronousReadThatTakesAWhileToExecute()在两个方法里都是直接在调用线程上同步执行的，没有任何异步调度逻辑。

具体拆解两个方法的执行流程 #

MethodA #

1. 立即同步执行SynchronousReadThatTakesAWhileToExecute()，阻塞调用线程直到该方法完成。
2. 用Task.FromResult()把构造好的ReadResponse包装成一个已完成状态的Task。
3. await这个已完成的Task：由于Task已经完成，await不会触发线程切换，只是直接提取Task的结果返回。
4. 因为方法带有async关键字，编译器会生成异步状态机，但这个状态机的开销微乎其微，对整体性能几乎无影响。

MethodB #

1. 立即同步执行SynchronousReadThatTakesAWhileToExecute()（因为Task.FromResult()的参数是直接计算的，不是委托），阻塞调用线程直到该方法完成。
2. 把同步方法的结果包装成已完成的Task。
3. await这个已完成的Task，直接提取结果。
4. 构造ReadResponse并返回，同样会生成异步状态机，开销和MethodA一致。

对你和同事观点的纠正 #

• 你认为MethodA会阻塞线程是对的，但MethodB也会完全一样地阻塞调用线程，因为两个方法里的耗时同步操作都没有被异步调度。
• 同事说两者表现一致是正确的，但“异步方法需始终返回Task”的表述不准确：方法签名要求返回Task<ReadResponse>所以必须返回，但这两个方法本质是伪装的异步方法——它们没有任何真正的异步IO或CPU绑定异步操作，只是用async/await和Task.FromResult包装了同步逻辑。
• 你关于await解包Task的理解是对的，但这里的await并没有带来任何异步收益，因为操作本身是同步完成的。

正确的异步改造方向 #

如果想让这个操作真正异步、不阻塞调用线程，应该用Task.Run()把同步方法放到线程池线程执行（仅适用于CPU绑定操作），或者如果有真正的异步API，直接调用异步版本：

public async Task<ReadResponse> ProperAsyncMethod(ReadRequest request)
{
    var response = await Task.Run(() => SynchronousReadThatTakesAWhileToExecute());
    return new ReadResponse(response);
}

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