C#中使用Task（无async/await）与async/await编写异步代码的差异

嘿，这个问题问得很到位！其实async/await本质上是C#编译器为Task异步模型封装的语法糖，但纯Task写法和async/await写法在代码体验、底层处理逻辑上有不少关键差异，结合你给出的例子来详细拆解：

1. 代码可读性与维护性：天差地别的写法体验 #

• 纯Task写法依赖ContinueWith串联异步后续操作，逻辑复杂时很容易陷入回调地狱。比如如果要连续执行3个异步操作，就得嵌套三层ContinueWith，代码缩进层层叠叠，可读性极差。
  你给出的纯Task例子里，已经能看到一点端倪：要在任务完成后打印日志，必须单独写一个ContinueWith回调，和主逻辑是分离的。
• async/await则是线性同步式写法，完全不需要回调嵌套。你的第二个例子里，await异步任务后直接写打印逻辑，和同步代码的结构一模一样，任何人看一眼就能理清执行顺序，维护成本低太多。

2. 状态机：编译器帮你做了所有脏活 #

• 当你用async/await时，C#编译器会自动生成一个状态机类，帮你处理异步流程的暂停与恢复：遇到await时，方法会立即返回一个未完成的Task；当await的Task完成后，状态机自动帮你回到暂停的位置，继续执行后续代码。整个过程完全不需要你手动干预。
• 纯Task写法里，所有的流程跳转都得你自己手动控制：用ContinueWith指定后续操作、手动处理线程切换、跟踪任务状态……相当于把编译器帮你做的工作全自己扛了，稍不注意就容易出错。

3. 异常处理：async/await更直观 #

• async/await可以直接用try/catch包裹整个异步流程，和同步代码的异常处理逻辑完全一致，所有在await前后抛出的异常都能被轻松捕获：

  static async Task DoWorkAsync() {
      try {
          await Task.Run(() => { throw new Exception("模拟出错"); });
          Console.WriteLine("Work Completed");
      } catch (Exception ex) {
          Console.WriteLine($"捕获异常：{ex.Message}");
      }
  }
  

• 纯Task写法的异常处理要麻烦得多：要么在ContinueWith里通过Task.Exception判断，要么调用Wait()/Result（但这会阻塞线程），而且如果是多步异步操作，异常处理会分散在各个回调中，很容易遗漏。比如你的纯Task例子如果抛出异常，得这么处理：

  static Task DoWorkAsync() { 
      var work = Task.Run(() => { throw new Exception("模拟出错"); }); 
      var workcompleted = work.ContinueWith(x => {
          if (x.Exception != null)
              Console.WriteLine($"捕获异常：{x.Exception.InnerException.Message}");
          else
              Console.WriteLine("Work Completed!!!"); 
      }); 
      return work; 
  }
  

4. 上下文捕获：async/await自动帮你切线程 #

• async/await默认会捕获当前的同步上下文（比如UI线程的SynchronizationContext），当await的任务完成后，会自动回到这个上下文执行后续代码。比如在WPF/WinForms里，await之后可以直接操作UI控件，完全不用手动切换线程。
• 纯Task的ContinueWith默认不会继承原上下文，如果需要回到原线程，得手动指定TaskScheduler.FromCurrentSynchronizationContext()作为参数，非常繁琐：

  var workcompleted = work.ContinueWith(x => {
      Console.WriteLine("Work Completed!!!"); 
      // 若是UI场景，这里要手动切回原线程
  }, TaskScheduler.FromCurrentSynchronizationContext());
  

5. 返回值处理：async/await自动包装Task #

• 当需要返回异步操作的结果时，async/await可以直接返回值，编译器会自动帮你包装成Task<T>，写法极其简洁：

  static async Task<int> GetValueAsync() {
      return await Task.Run(() => 42);
  }
  

• 纯Task写法要返回结果，得手动创建TaskCompletionSource<T>来设置返回值，代码冗余且容易出错：

  static Task<int> GetValueAsync() {
      var tcs = new TaskCompletionSource<int>();
      Task.Run(() => tcs.SetResult(42));
      return tcs.Task;
  }
  

你给出的纯Task例子里，返回的是work这个Task，但workcompleted这个后续打印操作的Task并没有被返回，所以调用方无法感知到“Work Completed!!!”这个操作是否完成；而async/await的例子里，整个方法的Task会等待await的任务完成，再执行打印逻辑，调用方拿到的Task包含了整个流程的完成状态——这也是两者在实际使用中很容易踩坑的点。

总的来说，除非你有特殊的底层异步流程定制需求，否则日常开发肯定优先用async/await，它把Task异步模型的复杂度完全封装起来，让你用同步代码的思维写异步逻辑，效率和可靠性都高得多。

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