Task.Run 就是带默认参数的 Task.Factory.StartNew
直接说结论：
Task.Run(action)在底层等价于：
Task.Factory.StartNew(action, CancellationToken.None, TaskCreationOptions.DenyChildAttach, TaskScheduler.Default)。它不是新机制，而是微软为简化常用场景封装的一层语法糖——省掉你手写那堆默认参数的麻烦。
所以如果你只是想“扔个 CPU 密集型工作到线程池里跑一下”，
Task.Run更干净、更安全、也更不容易出错。
Task.Run强制加了
TaskCreationOptions.DenyChildAttach：这意味着它内部不会把
async方法里
await后续产生的子任务（比如
Task.Run(() => { await SomeAsync(); }) 中的 SomeAsync()）自动挂到父任务上 而
Task.Factory.StartNew默认不加这个标记，子任务会“附加”到父任务，导致
await父任务时实际在等整个嵌套链结束——这常引发意料之外的等待行为 两者都默认走
TaskScheduler.Default（即线程池），都不创建新线程，除非你显式传
LongRunning
什么时候必须用 Task.Factory.StartNew？
只有当你需要
Task.Run不支持的控制能力时，才该切回去用
Task.Factory.StartNew。 要让任务长期独占一个线程（避免耗尽线程池）→ 必须用
TaskCreationOptions.LongRunning：
Task.Factory.StartNew(() => LongRunningWork(), TaskCreationOptions.LongRunning)要指定非默认调度器（比如 UI 线程调度器
TaskScheduler.FromCurrentSynchronizationContext()） 要组合多个选项（如
LongRunning | PreferFairness） 需要传递
CancellationToken且不想依赖
Task.Run的重载（虽然它也有，但
StartNew参数位置更直观）
注意：
Task.Run有带
CancellationToken的重载，但没有
LongRunning重载——这是最硬性的分水岭。
async/await 场景下最容易踩的坑
很多人把
async方法直接传给
Task.Run或
StartNew，结果发现行为不一致：
Task.Run(async () => await DoSomethingAsync()); // ❌ 返回 Task<Task>，需 .Unwrap() 或直接用 async lambda
正确写法是：
用Func<task></task>类型的 lambda：
Task.Run(() => DoSomethingAsync())→ 返回
Task，可直接
await或用
asynclambda（.NET 4.5+ 支持）：
Task.Run(async () => { await DoSomethingAsync(); }) → Task.Run能识别并自动
Unwrap但
Task.Factory.StartNew对
asynclambda 没这种智能处理，容易返回
Task<task></task>，必须手动
.Unwrap()
这也是为什么推荐优先用
Task.Run：它对异步委托做了适配，
StartNew则更“原始”，容易漏掉 unwrap。
别被“性能差异”误导
网上有些文章说
Task.Factory.StartNew“更快”或“更底层”，这是误解。两者开销几乎一样——
Task.Run就是调了一次
StartNew加几个固定参数。 真正影响性能的是你传的委托本身、是否阻塞、是否频繁创建任务，而不是选哪个 API 过度纠结“哪个更快”不如检查：任务是不是真该进线程池？有没有在 UI 线程里误用了
Wait()？CancellationToken 有没有及时响应？ 唯一真实差异点：若你忘了加
DenyChildAttach，又在
StartNew里用了嵌套
await，就可能让父任务意外延长生命周期，造成资源滞留
说到底，
Task.Run是为你省心的默认选项；
Task.Factory.StartNew是给你留的逃生舱门——用不用，在于你是否真的需要那扇门。
