控制台、Windows Forms、WPF的SynchronizationContext差异有哪些？

首先先明确你之前两个存在误差的认知点：

• 「ASP.NET中每个绑定HTTP请求的Task都会对应单独线程」的说法错误：.NET Framework版本的ASP.NET虽有自定义SynchronizationContext，但作用是将异步回调和当前HTTP请求上下文绑定，而非为每个Task分配独立线程；.NET Core及更高版本的ASP.NET已经移除了自定义SynchronizationContext，异步回调默认走线程池调度，行为和控制台应用一致。
• Task是异步操作的抽象层，和线程没有一一对应关系，SynchronizationContext的核心作用是定义异步操作完成后，后续回调代码的调度规则，而非直接管理Task的运行线程。

控制台应用 #

• 默认无自定义SynchronizationContext，SynchronizationContext.Current默认返回null
• 若await操作未配置ConfigureAwait(false)，由于没有自定义调度规则，回调会直接分配到线程池线程执行
• 无线程亲和性要求，所有异步回调可以运行在任意线程池线程上，不存在UI类应用常见的跨线程访问限制，也很难出现上下文导致的死锁问题

Windows Forms应用 #

• 存在自定义的WindowsFormsSynchronizationContext，仅在UI线程初始化时创建，和当前UI线程强绑定
• 核心调度规则：所有通过Post/Send方法提交的回调，都会通过Windows消息泵投递到绑定的UI线程执行，完全符合WinForms控件仅允许在创建线程上操作的要求
• 若在UI线程发起的await未配置ConfigureAwait(false)，await后的代码会回到UI线程执行；若配置了该参数，回调会运行在线程池线程上，此时直接访问UI控件会抛出跨线程访问异常
• 典型死锁场景：UI线程同步等待（调用.Wait()/.Result）一个未配置ConfigureAwait(false)的异步任务时，UI线程阻塞等待任务完成，而任务的回调已经投递到UI消息队列等待UI线程调度，二者互相等待形成死锁

WPF应用 #

• 存在自定义的DispatcherSynchronizationContext，和WPF的Dispatcher对象绑定，每个WPF UI线程对应唯一一个Dispatcher
• 核心调度规则：所有回调都会提交到关联的Dispatcher队列，按指定优先级执行，同样保证UI操作的线程亲和性
• 和Windows Forms SynchronizationContext的核心差异：
  • 调度支持优先级设置，WinForms的消息队列没有内置优先级区分能力
  • Dispatcher是WPF线程模型的核心组件，SynchronizationContext只是对Dispatcher调度能力的封装
  • 同样存在和WinForms一致的同步等待死锁问题，触发条件完全相同

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