C# SynchronizationContext.Current 线程差异解析

Windows Forms 主线程中 SynchronizationContext.Current 默认为 WindowsFormsSynchronizationContext，依赖 Control.InvokeRequired/BeginInvoke；WPF 主线程为 DispatcherSynchronizationContext；控制台应用恒为 null；ASP.NET Core 中始终为 null，传统 ASP.NET 请求线程中为 AspNetSynchronizationContext。

Windows Forms 中 SynchronizationContext.Current 的值

在 WinForms 主线程（UI 线程）上，SynchronizationContext.Current 默认是 WindowsFormsSynchronizationContext 实例。它内部依赖 Control.InvokeRequired 和 BeginInvoke 实现跨线程调度。

关键点：

• 只有调用过 Application.Run(new Form()) 或类似 UI 启动逻辑后，该上下文才被自动安装
• 若在 Program.Main 中未进入消息循环（比如只 new Form() 但没 Run），Current 为 null
• 在非 UI 线程（如 Task.Run 启动的线程）中，Current 始终为 null，不会自动继承

WPF 中 SynchronizationContext.Current 的行为

WPF 应用启动后，主线程（Dispatcher 线程）会自动设置 SynchronizationContext.Current 为 DispatcherSynchronizationContext，其底层绑定到当前 Dispatcher 实例。

注意：

• 该上下文与 Dispatcher.CurrentDispatcher 强关联，但二者不是同一个对象
• 若在后台线程手动调用 DispatcherSynchronizationContext 构造并赋值给 Current，需自行确保 Dispatcher 已存在且未关闭
• 在没有 Dispatcher 的线程（如纯 Thread.Start）中，Current 为 null，即使你引用了 WPF 程序集

.NET Core / .NET 5+ 控制台应用中的默认值

控制台应用默认不安装任何同步上下文，SynchronizationContext.Current 恒为 null，无论是否使用 async/await。

常见误解：

• await 在无上下文环境里会回到线程池线程继续执行，不是“保持原线程”
• 若需要模拟 UI 风格的同步（例如测试时强制回到某线程），必须显式创建并安装，如：

  var context = new SingleThreadSynchronizationContext();
  SynchronizationContext.SetSynchronizationContext(context);

• 第三方库（如某些测试框架）可能悄悄安装自定义上下文，导致行为与裸控制台不一致

ASP.NET（含 Core）请求上下文中的表现

ASP.NET Core 彻底移除了对 SynchronizationContext 的依赖，Current 始终为 null；而传统 ASP.NET（.NET Framework）在请求线程中会设置 AspNetSynchronizationContext，用于保障 HttpContext.Current 等上下文数据的线程一致性。

影响实际编码：

• 在 ASP.NET Core 中，ConfigureAwait(false) 是默认且无意义的——因为本来就没有上下文可捕获
• 在传统 ASP.NET 中，若禁用上下文（ConfigureAwait(false)），后续代码将无法访问 HttpContext.Current，抛出 NullReferenceException
• 跨请求生命周期（如托管服务、后台任务）中，Current 一定为 null，不能假设存在请求上下文

真正容易被忽略的是：上下文不是“线程属性”，而是“显式安装的全局变量”。它的存在与否、类型、生命周期，完全取决于宿主环境是否调用了 SynchronizationContext.SetSynchronizationContext(...) —— 而这个动作往往藏在框架初始化深处，不看源码很难察觉。