Task.Run如何避免异步代码死锁？对异步指南内容的困惑

我从某异步开发指南中了解到，若必须在UI线程（或单线程SyncContext环境）上阻塞异步代码，推荐使用Task.Run(()=>AsyncFunc()).Result来规避潜在死锁。指南给出的示例代码如下：

public string DoOperationBlocking()
{
    // Bad - Blocking the thread that enters.
    // DoAsyncOperation will be scheduled on the default task scheduler, **and remove the risk of deadlocking.**
    // In the case of an exception, this method will throw an AggregateException wrapping the original exception.
    return Task.Run(() => DoAsyncOperation()).Result;
}

文中提到该写法“……并消除死锁风险”，但我对此存在困惑：我知道Task.Run会把委托交给无SyncContext的线程池执行，不会占用当前SyncContext的线程，但按我的理解会出现死锁：

• Result调用会等待Task.Run返回的任务，阻塞当前UI线程；
• AsyncFunc执行完成后，因无SyncContext可以正常返回；
• 包装AsyncFunc的任务准备返回，但这个任务是在UI线程创建的，带有UI线程的SyncContext；
• 当前SyncContext只有一个线程，已经被Result阻塞；
• 包装任务无法标记为完成并设置结果；
• 最终发生死锁。

想请教为何该方式能避免死锁？

核心逻辑：包装任务的完成不依赖UI线程的SyncContext #

你对流程的误解出在第3步——Task.Run返回的包装任务，其完成逻辑完全不绑定UI线程的SyncContext，具体拆解如下：

1. Task.Run会把() => AsyncFunc()这个委托直接交给线程池执行，线程池线程默认没有同步上下文，所以整个AsyncFunc()的执行过程都处于无SyncContext的环境。
2. 当AsyncFunc()异步执行完毕后，它的后续收尾逻辑（标记包装任务完成、设置返回结果）会直接在线程池线程上执行，完全不需要回到UI线程的SyncContext。
3. 此时UI线程虽然被Result阻塞，但包装任务的完成通知不需要占用UI线程，线程池线程可以独立完成任务标记，Result就能立即拿到结果，不会出现死锁。

对比直接调用AsyncFunc().Result的死锁场景：
如果不用Task.Run，AsyncFunc()在UI线程启动，异步操作完成后会试图回到UI线程的SyncContext继续执行后续逻辑，但此时UI线程已经被Result阻塞，导致异步逻辑无法收尾，最终形成死锁。而Task.Run通过把整个异步逻辑转移到无同步上下文的线程池，从根源上切断了对UI线程SyncContext的依赖，自然不会触发死锁。

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