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<T>时自动.Unwrap()，比如Task.Run(() => Task.Delay(100))直接得到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>，它返回的是Task<Task<T>>，必须手动.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 可能仍在线程池中调度，但会尽量分配独立线程 - 别滥用：仅当任务真正「长+阻塞」才用，否则反而降低吞吐量
StartNew 在 UI 线程里悄悄用了 Dispatcher 调度器。 
