无并发场景下使用async/await是否仍具系统价值？

好问题！咱们得先把async/await的核心逻辑理清楚，再来看这种写法到底有没有用。

首先明确一个关键点：async/await的核心是异步等待，而非并行——它的优势是在等待耗时操作（尤其是IO绑定操作，比如数据库查询、网络请求）的时候，把当前占用的线程还给线程池，让这个线程能去处理其他任务，而不是原地阻塞浪费资源。

接下来咱们分情况看你提到的这种写法：

static async Task Main(string[] args) { 
  await DoTask1Async(2); 
  DoSomething(); 
}

情况1：DoTask1Async是真正的IO绑定异步操作 #

如果DoTask1Async内部是真正的非阻塞IO操作（比如调用HttpClient.GetAsync、EF Core的异步查询这类），那这行await DoTask1Async(2)就非常有价值：

• 当代码执行到await时，DoTask1Async会启动IO操作，然后立即返回一个未完成的Task；
• 此时当前线程会被释放回线程池，这个线程可以去处理其他需要它的任务（比如ASP.NET里处理另一个用户的请求，或者后台的其他异步任务）；
• 等IO操作完成后，线程池会再分配一个线程（不一定是之前的那个）来继续执行后续的DoSomething()。

这种情况下，整个系统的线程资源利用率会大幅提升，完全不是“无用”的写法——这也是async/await在IO密集型场景下最大的价值之一。

情况2：DoTask1Async是“假异步” #

如果DoTask1Async只是用Task.Run包装了同步代码，或者内部直接返回一个已完成的Task（比如return Task.CompletedTask），那这种写法和传统同步代码几乎没有区别：

• await的时候不会释放线程，线程会一直阻塞到任务完成；
• 后续的DoSomething依然是串行执行，完全没发挥异步的优势。

这种场景下，这个写法确实没什么额外价值，和直接写同步代码效果一样。

和并发写法的区别 #

你提到的另一种并发写法：

static async Task Main(string[] args) { 
  var task1= DoTask1Async(2); 
  DoSomething(); 
  await task1; 
}

这是主动让DoTask1Async和DoSomething并发执行，属于利用异步实现并行的场景；而你问的串行写法是保证执行顺序，但依然能在等待期间释放线程资源——两者的适用场景不同，不能说串行写法就没用。

总结一下：这种串行的await写法不是完全无用，它的价值取决于你的异步方法是否是真正的IO绑定操作。如果是，它能帮系统更高效地利用线程资源；如果是假异步，那确实和同步代码没差。

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