c# Task.Run 和 Task.Factory.StartNew 的默认 TaskScheduler 有什么不同

Task.Run 默认使用 TaskScheduler.Default（线程池调度器），不捕获同步上下文，适合后台任务；Task.Factory.StartNew 默认用 TaskScheduler.Current，可能捕获 UI 调度器导致卡顿或异常，需显式指定 TaskScheduler.Default 规避风险。

Task.Run 默认用 TaskScheduler.Default，安全省心

当你写 Task.Run(() => DoWork())，它**强制使用线程池调度器**——也就是 TaskScheduler.Default。这个行为是硬编码的，不依赖当前上下文。哪怕你在 UI 线程（如 WinForms/WPF 主线程）或 ASP.NET Core 的请求上下文中调用，它也绝不会把任务塞回 UI 线程去执行。

• 适合绝大多数后台计算、I/O 绑定等非 UI 操作
• 不会意外捕获 SynchronizationContext，避免“本该后台跑，结果卡死 UI”的坑
• 返回 Task 时自动 .Unwrap()，比如 Task.Run(() => Task.Delay(100)) 直接得到 Task，不是 Task

Task.Factory.StartNew 默认用 TaskScheduler.Current，容易踩上下文陷阱

Task.Factory.StartNew(() => DoWork()) 的默认调度器是 TaskScheduler.Current —— 它会“看人下菜”：如果当前线程绑定了调度器（比如 WPF 的 DispatcherSynchronizationContext 或旧版 ASP.NET 的 AspNetSynchronizationContext），它就可能把任务扔进那个调度器里执行。

• 在 UI 线程中调用，可能让 StartNew 的工作在 UI 线程上同步执行 → 卡界面
• 后续 .ContinueWith(...) 默认也在同一调度器上运行，容易误入 UI 线程引发跨线程异常
• 若委托返回 Task，它返回的是 Task>，必须手动 .Unwrap() 才能扁平化
• 要规避风险，必须显式传入 TaskScheduler.Default：

  Task.Factory.StartNew(() => DoWork(), TaskScheduler.Default);

怎么验证当前用的是哪个调度器？

最直接的办法是打印线程 ID 和调度器类型：

Console.WriteLine($"Current scheduler: {TaskScheduler.Current.GetType().Name}");
Console.WriteLine($"Default scheduler: {TaskScheduler.Default.GetType().Name}");
Console.WriteLine($"Thread ID: {Thread.CurrentThread.ManagedThreadId}");

• Task.Run 下始终看到 ThreadPoolTaskScheduler 和一个非 UI 线程 ID
• Task.Factory.StartNew（无参数）在 WPF/WinForms 中可能显示 DispatcherTaskScheduler 或类似 UI 相关类型

长期运行任务（LongRunning）不能靠 Task.Run

如果你的任务预计持续数秒以上、会阻塞线程（比如密集循环、同步 I/O、长时间等待），Task.Run 无法帮你绕过线程池饥饿问题——它永远走线程池，且不支持 TaskCreationOptions.LongRunning。

• 这时必须用 Task.Factory.StartNew 并显式指定：

  Task.Factory.StartNew(() => LongRunningWork(), 
      CancellationToken.None, 
      TaskCreationOptions.LongRunning);

• 注意：LongRunning 是提示，不是保证；.NET Runtime 可能仍在线程池中调度，但会尽量分配独立线程
• 别滥用：仅当任务真正「长+阻塞」才用，否则反而降低吞吐量

真正容易被忽略的点是：**默认调度器差异不是“风格不同”，而是“是否隐式绑定上下文”的本质区别**。很多诡异的 UI 卡顿或跨线程异常，源头就是没意识到 StartNew 在 UI 线程里悄悄用了 Dispatcher 调度器。