AsyncFunction直接调用GetResult与Task.Run包裹后调用的差异及死锁原因

首先明确Blazor Server的运行前提：Blazor Server的UI交互全程绑定了单线程同步上下文（SynchronizationContext），该上下文同一时间仅允许一个操作执行，且异步方法默认await会捕获当前同步上下文，等待异步操作完成后回到原上下文执行剩余代码。

直接调用AsyncFunction(...).GetAwaiter().GetResult()的死锁原因 #

你代码中的GetAwaiterGetResultOnFunction方法走的是这个逻辑，死锁的流程如下：

1. 按钮点击事件触发后，方法直接在Blazor UI同步上下文上运行，调用AsyncFunction直到命中await Task.Delay(500)，此时AsyncFunction返回未完成的Task<string>对象，且await已经捕获了当前的Blazor UI同步上下文，等待Task.Delay完成后要回到该上下文执行返回逻辑。
2. 紧接着调用的.GetAwaiter().GetResult()会同步阻塞当前的UI上下文线程，强制等待前面返回的Task执行完成。
3. 500ms后Task.Delay执行完成，AsyncFunction的剩余返回逻辑需要申请Blazor UI同步上下文才能执行，但该上下文线程已经被GetResult()堵死，永远无法腾出资源执行后续逻辑，Task永远处于未完成状态，形成死锁。

被Task.Run包裹后不会死锁的原因 #

Task.Run的核心作用是将传入的委托调度到线程池线程执行，线程池线程没有绑定Blazor的UI同步上下文，整个执行流程不存在资源竞争：

1. 按钮点击事件触发后，Task.Run将AsyncFunction的执行逻辑调度到线程池线程运行，UI线程仅持有Task.Run返回的Task对象。
2. 线程池线程执行AsyncFunction到await Task.Delay(500)时，因为当前线程没有绑定Blazor UI同步上下文，await默认捕获的是线程池任务调度器，Task.Delay完成后直接在线程池线程执行剩余的返回逻辑，完全不需要申请Blazor UI同步上下文。
3. UI线程调用.GetAwaiter().GetResult()仅阻塞自身，等待线程池的Task执行完成，两边不存在循环等待的资源竞争，线程池的Task执行完成后会直接把结果返回给UI线程，阻塞解除，不会触发死锁。

两种调用的核心区别 #

• 执行上下文不同：直接调用AsyncFunction时，方法全程在Blazor UI同步上下文执行，await会捕获该上下文用于后续代码执行；被Task.Run包裹后，AsyncFunction全程在线程池上下文执行，不会依赖Blazor UI同步上下文。
• 资源竞争逻辑不同：直接调用时，GetResult()阻塞了UI上下文，异步方法后续执行又要等待UI上下文释放，形成循环等待的死锁条件；Task.Run包裹后异步方法的执行完全不依赖UI上下文，和被阻塞的UI线程没有资源竞争，不满足死锁的必要条件。

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