Task.Run 默认用 TaskScheduler.Default
，安全省心
当你写
Task.Run(() => DoWork())，它**强制使用线程池调度器**——也就是
TaskScheduler.Default。这个行为是硬编码的，不依赖当前上下文。哪怕你在 UI 线程（如 WinForms/WPF 主线程）或 ASP.NET Core 的请求上下文中调用，它也绝不会把任务塞回 UI 线程去执行。 适合绝大多数后台计算、I/O 绑定等非 UI 操作 不会意外捕获
SynchronizationContext，避免“本该后台跑，结果卡死 UI”的坑 返回
Task<t></t>时自动
.Unwrap()，比如
Task.Run(() => Task.Delay(100))直接得到
Task，不是
Task<task></task>
Task.Factory.StartNew 默认用 TaskScheduler.Current
，容易踩上下文陷阱
Task.Factory.StartNew(() => DoWork())的默认调度器是
TaskScheduler.Current—— 它会“看人下菜”：如果当前线程绑定了调度器（比如 WPF 的
DispatcherSynchronizationContext或旧版 ASP.NET 的
AspNetSynchronizationContext），它就可能把任务扔进那个调度器里执行。 在 UI 线程中调用，可能让
StartNew的工作在 UI 线程上同步执行 → 卡界面 后续
.ContinueWith(...)默认也在同一调度器上运行，容易误入 UI 线程引发跨线程异常 若委托返回
Task<t></t>，它返回的是
Task<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 调度器。
