为何ExecuteSynchronously不是async/await的默认选项？

首先要澄清一个细节：async/await的底层状态机实现并非直接调用ContinueWith，但两者在延续任务的调度逻辑上有相似的设计考量。回到你的问题，默认不使用ExecuteSynchronously主要有以下几个核心原因：

• 线程池负载均衡优先
  线程池的核心目标是高效调度任务，让线程快速完成工作并回到池内待命。如果强制让完成异步任务的线程（比如threadA）同步执行后续代码，若后续的同步操作（比如methodNonAsync()）耗时较长，threadA会被长时间占用，无法及时处理线程池中的其他任务，反而降低整体吞吐量。只有当后续代码是极短的“收尾”逻辑时，同步执行才会有性能优势，但这种场景并非普遍情况。

• 上下文一致性的保障
  async/await默认会捕获当前的同步上下文（比如UI线程上下文、ASP.NET请求上下文），后续代码需要在这个上下文中执行才能保证正确性——比如UI线程必须回到自身上下文更新控件，否则会抛出跨线程异常。如果使用ExecuteSynchronously，后续代码可能直接在完成异步任务的线程池线程上执行，跳过上下文切换，这会破坏依赖上下文的业务逻辑的正确性。

• 避免死锁风险
  在存在同步上下文的环境中（比如旧版ASP.NET、WinForms/WPF），如果强制同步执行延续任务，很容易触发死锁。举个例子：主线程调用asyncMethod().Wait()阻塞等待，而异步任务完成后，延续代码需要回到主线程执行，但主线程已经被阻塞，导致延续任务无法执行，最终形成死锁。默认的调度逻辑通过将延续任务放入上下文队列，避免了这类风险。

• 通用性与灵活性的权衡
  .NET团队的设计优先保证async/await在绝大多数场景下的正确性和通用性，而非针对特定场景做极端性能优化。如果开发者确定后续代码不需要上下文、且执行时间极短，可以通过ConfigureAwait(false)来允许延续任务在任意线程（包括完成异步任务的线程）上执行，手动获得同步执行的性能收益。

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