为何在C#中使用Tasks与async/await却立即等待？

先看你提到的两种写法对比：

异步版本：

public async Task<User> GetUserAsync(int id, CancellationToken cancellationToken = default)
{
    return await _unitOfWork.Users.SingleOrDefaultAsync(x => x.Id == id, cancellationToken);
}

同步版本：

public User GetUser(int id)
{
    return _unitOfWork.Users.SingleOrDefault(x => x.Id == id);
}

这种“发起异步请求后立即await”的写法完全有实际意义，它和同步版本的核心差异不在当前方法内的并行执行，而在于线程资源的高效利用以及异步生态的适配，尤其是在Web场景下：

1. 大幅提升Web服务器的并发处理能力 #

同步方法执行IO操作（比如数据库查询）时，会一直占用一个线程池线程，直到IO完成。而异步方法在awaitIO操作的瞬间，会把线程归还给线程池，让这个线程可以去处理其他用户的请求。等IO操作完成后，再从线程池获取空闲线程继续执行后续逻辑。

在高并发场景下，这种机制能避免线程池被耗尽，让服务器能同时处理更多请求。比如1000个并发的数据库查询，同步写法需要占用1000个线程，而异步写法可能只需要几十个线程就能支撑——因为大部分时间线程都在被复用处理其他请求，而非阻塞等待IO。

2. 原生支持取消操作 #

异步方法可以通过CancellationToken接收取消信号，比如用户中途关闭浏览器、请求超时等场景，Web框架会触发取消，数据库的异步查询能及时终止，避免无效的资源消耗。

同步方法很难做到这一点：要么只能依赖数据库自身的超时机制，要么需要额外的复杂逻辑才能中断阻塞的IO操作，成本高且效果差。

3. 维持统一的异步编程链 #

保持从Web API控制器Action到Service再到EF的全异步调用链，能避免“同步阻塞异步”的常见坑（比如误用.Result或.Wait()导致线程死锁）。统一的异步模型让代码风格一致，后续如果需要扩展并行逻辑（比如你提到的在await前加其他计算），不需要重构整个调用链，直接修改局部代码即可。

4. 底层真正的异步IO支持 #

EF的SingleOrDefaultAsync是基于操作系统的异步IO实现的（不是用线程模拟的伪异步），在等待数据库响应时，操作系统不会占用线程资源。而同步调用的SingleOrDefault会让线程阻塞等待IO完成，这是本质的资源利用差异。

关于“只有并行工作时才有用”的误解 #

异步的核心价值不是方法内的并行执行，而是在IO等待期间释放线程，让服务器能更高效地利用资源。即使你没有在await前加其他代码，这种写法依然能为整个系统的吞吐量做出贡献——这也是为什么GitHub上大量项目都采用这种写法的原因。

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