基于自定义同步上下文的Sync-over-Async实现潜在缺陷问询

RestSharp的AsyncHelpers类通过替换同步上下文在原线程中等待异步操作，看似解决了传统Task.Run(...).Result的死锁问题，还保留了HttpContext.Current，但这套实现存在不少容易踩的陷阱：

• 线程池耗尽与吞吐量下降：在ASP.NET（非Core）这类依赖有限线程池处理请求的场景中，原请求线程会被同步阻塞至异步操作完成。高并发下，大量线程被占住无法释放，会导致新请求排队等待，系统吞吐量急剧下降，甚至引发服务无响应。
• 嵌套同步上下文冲突：如果异步代码内部存在未使用ConfigureAwait(false)的await调用，或者嵌套调用AsyncHelpers的同步等待方法，会导致自定义同步上下文与原上下文（比如WinForms/WPF的UI上下文）嵌套叠加，可能触发死锁，或者导致UI线程长时间卡死无法刷新。
• 异常处理逻辑不一致：异步操作抛出的异常会被包装进AggregateException，而非像直接await那样直接抛出原始异常。开发者若按常规异步异常处理逻辑编写代码，容易忽略内层异常，增加调试排查的难度。
• 自定义同步上下文兼容性问题：若原线程依赖非标准的自定义同步上下文（比如某些框架的日志、权限验证上下文），AsyncHelpers替换上下文的操作会破坏原上下文的状态，导致后续依赖该上下文的功能失效，且这类问题很难提前预判。
• 取消机制失效：如果异步操作支持CancellationToken，同步等待期间线程处于阻塞状态，无法及时响应取消信号。即便外部触发取消，也只能等到异步操作自然完成，无法实现及时终止，浪费资源。
• 性能损耗明显：虽然避免了额外线程的创建，但阻塞原线程的本质依然是浪费线程资源。在IO密集型场景中，纯异步调用能让线程处理更多其他任务，而这套实现的吞吐量会远低于纯异步方案。
• 调试复杂度提升：自定义同步上下文的切换会打乱异步代码的执行栈，调试时难以追踪异步操作的执行顺序、上下文状态变化，定位问题的成本大幅增加。

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