为何Task.Wait()未包裹Task.Run时失效？求原因与解决方案

• 核心是同步上下文阻塞导致的死锁：
  当你在带有同步上下文的线程（比如UI线程、传统ASP.NET请求线程）中调用DoWork().Wait()时，Call方法内的await DoAnotherWorkAsync()执行到await时会释放当前线程，等异步操作完成后，默认会试图回到原来的同步上下文继续后续逻辑。但此时原来的线程已经被Wait()阻塞，正等待Task完成；而Task又在等待同步上下文空闲才能继续执行，形成循环等待，也就是死锁。
• Task.Run能解决的原因：Task.Run会将DoWork的执行转移到线程池线程，这类线程没有绑定同步上下文。await完成后会直接在线程池线程上继续执行，不会试图回到被阻塞的原线程，因此不会触发死锁。

1. 异步到底（推荐最佳实践） #

将Execute改为异步方法，用await替代阻塞式的Wait()，从根源避免死锁，同时符合异步编程的设计原则：

public async Task Execute(ref param1, ref param2)
{
   // 原有逻辑
   await someInstance.DoWork();
}

注意：调用Execute的上层方法也需要同步改为异步，保持异步链完整，不要在中间插入阻塞操作。

2. 取消同步上下文捕获 #

如果必须保留Execute的同步方法，可以在await时添加ConfigureAwait(false)，让异步操作完成后不回到原同步上下文：

private async Task Call()
{
    await DoAnotherWorkAsync().ConfigureAwait(false);
}

这样await完成后会直接在线程池线程继续执行，不会等待被Wait()阻塞的原同步上下文，从而避免死锁。

3. Task.Run包裹（应急方案） #

就是你已经使用的方式，但这是次优选择——它会额外占用线程池资源，且如果DoWork内部有依赖原同步上下文的逻辑可能引发问题，仅适合临时应急场景。

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