不会死锁但不安全：ConfigureAwait(false) 对 GetAwaiter().GetResult() 无效，后者仍会同步阻塞当前线程，若在UI或ASP.NET等有同步上下文的环境中调用，会导致线程挂起，浪费资源且易引发性能问题。

ConfigureAwait(false) 后调用 GetAwaiter().GetResult() 会死锁吗？

不会死锁，但不安全——GetAwaiter().GetResult() 仍可能在同步上下文中阻塞线程，而 ConfigureAwait(false) 只影响 await 的后续调度，对同步等待无任何作用。

ConfigureAwait(false) 的效果仅在 await 表达式中生效；一旦你改用 GetAwaiter().GetResult()，就绕过了整个 await 状态机的调度逻辑，直接同步阻塞当前线程等待完成。这意味着：

• ConfigureAwait(false) 在这里完全被忽略，等价于没写
• 如果当前线程有同步上下文（如 WinForms 主线程、WPF Dispatcher、ASP.NET（旧版）HttpContext），GetResult() 仍会卡住它
• 即使没有同步上下文，也会浪费线程资源，失去异步优势

为什么有人误以为这样能“避免死锁”？

常见误解源于混淆了两种不同机制：一个是 await 的延续调度控制（ConfigureAwait 起作用），另一个是同步等待（GetResult 完全无视调度设置）。

典型错误场景是：在 UI 线程里写

var result = SomeAsync().ConfigureAwait(false).GetAwaiter().GetResult();

真正安全的替代方案有哪些？

除非你明确处于无同步上下文的纯后台线程（如 Task.Run 内部），否则应避免同步等待。更合理的做法是：

• 向上游传播 async/await：把调用方也改成 async Task 方法，用 await SomeAsync().ConfigureAwait(false)
• 若必须同步（如某些框架入口点不支持 async），用 Task.Run(() => SomeAsync()).Unwrap().GetAwaiter().GetResult()，确保在 ThreadPool 线程上执行，避开 UI/ASP.NET 上下文
• 在 ASP.NET Core 中，已默认无 SynchronizationContext，但依然不推荐 GetResult() —— 它会阻塞线程池线程，降低吞吐量

ConfigureAwait(false) 和 GetResult() 组合的性能与可维护性代价

这个组合既没带来安全性，也没带来性能收益，反而增加理解成本和隐藏风险：

• 代码看起来“很异步”，实则同步阻塞，误导后续维护者
• 异常堆栈会丢失 await 点信息，GetResult() 抛出的是 AggregateException 包裹原始异常，调试更麻烦
• 在高并发服务中，大量 GetResult() 会快速耗尽线程池，引发请求堆积甚至超时

真正需要警惕的，不是 ConfigureAwait(false) 加得够不够，而是有没有把同步等待当成“简单解法”来滥用。