await与Task.Result的区别解析：为何await看似阻塞却非同步阻塞？

问题背景 #

调用异步方法会返回Task<T>类型对象，其中T为结果类型。目前有两种处理该任务的方式：一是使用.Result属性等待任务完成并获取包装值，二是使用await关键字。两者看似作用相同，实则存在差异。

看到@Frank Fajardo的回复提到：await会异步解包任务的结果[...] Result会阻塞[...]，但实际测试代码显示，无论使用await barAsync()还是fooTask().Result、barAsync().Result，foo()都只会在对应任务完成后才被调用，这让人疑惑：await难道不会阻塞Main()方法的执行吗？await与.Result的核心区别究竟是什么？使用await时不会被阻塞的是哪个线程？

测试代码如下：

using System;
using System.Threading;
using System.Threading.Tasks;

public class App
{
    public static async Task Main(string[] args)
    {
        Console.WriteLine (await barAsync());
        Console.WriteLine (foo());
        
        Console.WriteLine (fooTask().Result);
        Console.WriteLine (foo());
        
        Console.WriteLine (barAsync().Result);
        Console.WriteLine (foo());
    }
    
    public static Task<string> fooTask()
    {
        return Task.Run(() => {
           Thread.Sleep(1000);
           return "faz";
        });
    }
    
    public static async Task<string> barAsync()
    {
       Thread.Sleep(5000);
       return "baz";
    }
    
    public static string foo()
    {
       return "--- faz ---";
    }
}

核心区别解析 #

1. 线程处理逻辑的本质差异 #

• .Result：强制阻塞当前线程
  调用.Result时，当前线程会被直接挂起，完全占用直到任务完成。在测试代码里，Main线程会一直等待异步任务结束，期间无法处理任何其他工作。更危险的是，在同步上下文（如UI线程、旧版ASP.NET上下文）中使用.Result极易引发死锁：任务需要等待上下文空闲才能继续，但当前线程被.Result阻塞占着上下文，最终导致任务和线程互相等待、无法推进。

• await：释放当前线程，后续代码异步恢复
  await的核心是"让出当前线程"：当遇到await且任务未完成时，当前线程会被放回线程池（或释放同步上下文），去处理其他待执行的任务。等异步任务完成后，框架会自动安排合适的线程（可能是原线程，也可能是线程池新线程）继续执行await之后的代码。
  测试代码中await看起来"阻塞"了Main，是因为Main本身是按顺序执行的异步方法，它会等待每个异步操作完成后再往下走，但这个过程中Main所在的线程并没有被持续占用——如果此时有其他任务需要执行，线程可以去处理。比如改成await Task.WhenAll(barAsync(), fooTask())，就能看到线程被复用的效果。

2. 异常处理的差异 #

• .Result会将任务抛出的异常包装为AggregateException，需要从InnerExceptions中提取原始异常。
• await会直接抛出原始异常，无需额外拆包，更符合常规异常处理逻辑。

3. 同步上下文的处理 #

• .Result完全忽略同步上下文，直接阻塞当前线程。
• await默认会捕获当前同步上下文（如UI线程上下文），任务完成后会回到该上下文继续执行后续代码（可通过ConfigureAwait(false)跳过此行为，提升性能）。

关于"不会被阻塞的线程" #

使用await时，执行await操作的当前线程会被释放，它可以转而处理其他任务。比如在UI程序中，UI线程遇到await后会回到消息循环处理用户操作，不会导致界面卡死；在ASP.NET中，请求线程会被放回线程池，处理其他请求。

而await之后的代码，会在任务完成后由框架安排合适的线程继续执行——不一定是原来的线程，但逻辑上是"接着之前的位置继续"，所以从整体流程看，没有出现线程被持续占用的阻塞情况。

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