同一个异步方法，控制台程序里跑得好好的，搬到WinForms或WPF上，按钮点下去窗口立刻失去响应：标题栏变灰显示未响应，CPU占用0%，日志文件里没有任何异常。放到经典ASP.NET上则是请求永不返回，浏览器一直转圈，IIS里的队列越堆越长。
这三种表现背后是同一个原因。
为什么会卡住
await编译后是一个状态机。执行到await这一行时，默认情况下会把当前的SynchronizationContext记下来（没有上下文时退化为记TaskScheduler），等被等待的操作完成，再把后半段方法通过Post送回这个上下文继续执行。
而UI线程的上下文一次只处理一个消息，await后面的代码要想跑起来，得先让UI线程空下来。
Task.Result、Task.Wait()、task.Wait() 做的是相反的事：把当前线程原地阻塞，直到任务完成。
两边凑到一起就完了。UI线程被阻塞后不再处理消息队列，await的后半段排不进去，Task永远完不成，阻塞也永远不会解除。这个坑现场遇到过不止一次，现象都是一按就死，抓下来的主线程堆栈全是wait。
哪些环境踩得到
只有带SynchronizationContext的环境才有这个死锁条件。WinForms是WindowsFormsSynchronizationContext，WPF是DispatcherSynchronizationContext，经典ASP.NET（System.Web）是AspNetSynchronizationContext，MAUI也一样有。控制台程序、ASP.NET Core、单元测试里的普通Task.Run，SynchronizationContext.Current取值是null。
判断当前环境有没有这个上下文，一行代码就能看出来：
Debug.WriteLine(SynchronizationContext.Current?.GetType().FullName ?? "这里没有上下文");
打印出来是null的环境，同步阻塞不会死锁，代价会变成线程池饿一阵子。
这套机制自 .NET Framework 4.5引入async/await之后就没改过，一直到最新的运行时都是同一个行为。手头常年混着.NET Framework 4.5、4.6.2、4.8，加上 .NET Core 2.1、3.0、3.1，往上还有ASP.NET Core 6.0、8.0，这么多版本之间的差别只在有没有上下文，不在await本身。C# 5.0、7.1、8.0、13.0，语言层每次升级也没碰过「默认捕获上下文」这条规则。2025年发布的 .NET 10上，这条规则照旧。
怎么确认是不是它
1、桌面端最好判断。用Visual Studio附到进程上，等卡住之后点全部中断，看主线程的调用堆栈。往上翻，看到Monitor.Wait、ManualResetEventSlim.Wait，中间再没有任何业务方法，就是典型的同步阻塞。Visual Studio 17.11、17.12、17.13，这几个版本的并行堆栈视图会更省事，能把各线程的调用关系摊开。
2、WinDbg那边加载sos之后，用clrstack看托管堆栈，用syncblk查是哪一个Monitor被占着。符号拉不下来的时候换成dotnet-stack report，输出里同样能看到线程停在Wait。
3、ASP.NET Core上没有死锁，但同步阻塞会变成另一种故障。线程池扩容很慢，超过最小线程数之后大约每0.5秒才注入一个新线程，请求涨得比线程池补得快，症状是CPU很低、接口却全线变慢直到超时。
四种改法，按推荐程度排
1、await一路传上去，这是唯一的正解。被调用的这一层改成async Task，调它的上一层也改成async Task，一直改到不能再拆的地方。控制台入口写成async Task Main（C# 7.1起支持），WinForms的事件处理器写成async void属于允许范围，因为它本来就是事件。
2、被调用的方法里给每一个await加ConfigureAwait(false)。关键点在「每一个」——只在第一个await上加，后面的照样会捕获上下文。加了之后续体会落到线程池线程，UI线程不再被等待，死锁随之消失。库代码尤其要整段加，否则下游某个人写了 .Result，就把死锁替上游触发出来了。
public async Task<string> GetDataAsync()
{
await _stream.FlushAsync().ConfigureAwait(false);
return await _reader.ReadToEndAsync().ConfigureAwait(false);
}
3、临时止血可以用Task.Run包一层：把异步调用整个丢给线程池，外层再同步等结果。
var r = Task.Run(async () => await GetDataAsync()).GetAwaiter().GetResult();
Task.Run内部没有UI上下文，await之后会回线程池线程，死锁条件不成立。应急可以，长期还是该改签名。
4、实在没法异步的那一步，取结果优先用 .GetAwaiter().GetResult()，别用 .Result和 .Wait()。三者的死锁风险一样，差别在异常：.Result与 .Wait() 会把真实异常包进AggregateException，日志里看到的是一层壳；GetAwaiter().GetResult() 抛出原始异常，堆栈直接指到出事的那行。
另外三个连带会踩到的地方
async void除了事件处理器以外都不该写。它没有Task交还给调用方，异常会直接冒到SynchronizationContext上变成进程级未处理异常，调用方套的try/catch一个都拦不住，单元测试也没法await它。
还有一种更隐蔽的写法，用下划线把Task丢掉，样子是fire and forget。异常同样被吞，而且会拖到Task被回收时才通过TaskScheduler.UnobservedTaskException冒出来，日志里既没有当时的上下文，也对不上业务现场。真要后台跑，至少接一个ContinueWith把异常打出来。
lock块里不能写await，编译器会直接报CS1996。原因是await之后的续体可能跑到另一个线程上，而Monitor是由进入的那个线程负责释放的，跨线程Exit会抛SynchronizationLockException。异步场景要做互斥，换成SemaphoreSlim配WaitAsync。
这里还有个新坑：C# 13与 .NET 9起，如果锁对象声明成System.Threading.Lock类型，出现在async方法里的lock会报CS9217，提示这种类型的Lock值不能用于异步方法和异步lambda。看到这个错别往Monitor上怀疑，把类型换回object，或者直接改用SemaphoreSlim就行。
动手之前先在出问题的机器上确认目标框架是哪一个，别照着别的版本的文档改。