GetAwaiter().GetResult() 是最常踩的坑，因它看似同步实则阻塞线程且易致死锁，尤其在 UI 或 ASP.NET 同步上下文中；不释放上下文、不支持取消、异常难追踪，仅适用于无同步上下文的控制台主函数或单元测试。
为什么 GetAwaiter().GetResult() 是最常踩的坑
它看起来像同步调用，实际会阻塞当前线程并可能引发死锁——尤其在 UI 线程或 ASP.NET 同步上下文里。比如在 WinForms 事件处理器中写 var result = SomeAsyncMethod().GetAwaiter().GetResult();，UI 线程被占住，而异步操作内部又尝试回调到该线程，直接卡死。
- 它不释放上下文，也不支持取消，错误堆栈也难追踪
- 和
.Result行为一致，但后者还可能包装AggregateException，更难调试 - 仅适合极少数场景：控制台主函数入口、单元测试 setup（且需确保无同步上下文）
ASP.NET Core 中 async void 为什么比 async Task 更危险
async void 方法无法被等待，异常会直接抛给 SynchronizationContext，导致进程崩溃或静默丢失；而 ASP.NET Core 默认没有全局异常处理器捕获这类异常。
- 控制器动作方法必须返回
Task或Task<T>，返回void会绕过框架的请求生命周期管理 - 事件处理（如
Button.Click += async void (...) {...}）在 WebAssembly 或 Blazor Server 中同样不可靠 - 日志里看不到未捕获异常，监控也收不到，问题暴露滞后
如何安全地“同步等待”一个 Task（真有这需求时）
绝大多数情况不该这么做。但如果集成旧代码、测试断言或极简 CLI 工具，且明确知道运行环境无同步上下文（如 .NET 6+ 控制台应用），可用以下方式：
var task = SomeAsyncMethod(); task.Wait(); // 比 GetResult() 稍好：异常原样抛出，不包 AggregateException // 或更稳妥： task.ConfigureAwait(false).GetAwaiter().GetResult(); // 显式放弃上下文捕获
-
ConfigureAwait(false)是关键，它告诉编译器“别试图回到原始上下文”，避免死锁 - 仍要配合
try/catch处理TaskCanceledException和业务异常 - 永远不要在库代码中暴露同步包装方法（如
DoSomething()+DoSomethingAsync()），这会把阻塞风险传递给调用方
Task.Run(() => { ... }).Result 真的安全吗？
不安全。它只是把同步阻塞移到了线程池线程上，看似没卡主线程，实则浪费线程资源、增加调度开销，并可能引发线程池饥饿——尤其高并发场景下大量 Task.Run(...).Result 会拖垮整个应用吞吐。
- 它不是“异步转同步”的正确解法，而是用资源换表象
- 若原方法本就 CPU 密集，应改用
Task.Run+await，而不是.Result - ASP.NET Core 中禁止在请求处理路径里调用它，中间件或过滤器里出现会被诊断工具标记为高风险
await 就自动解决。 
