ThreadPool.QueueUserWorkItem 是“裸线程池调用”，Task.Run 是“带包装的线程池调度”
两者底层都用的是同一个
ThreadPool，但
Task.Run不只是语法糖——它加了任务生命周期管理、异常捕获、返回值支持和组合能力。而
ThreadPool.QueueUserWorkItem是纯委托投递，不返回任何对象，出错就直接崩（除非你手动 try/catch）。
ThreadPool.QueueUserWorkItem返回
void，无法 await，无法 .Wait()，无法链式续跑
Task.Run返回
Task或
Task<tresult></tresult>，天然支持
await、
ContinueWith、
WhenAll等 异常处理：前者未捕获异常会终结进程；后者异常被封装进
Task.Exception，可安全 await + catch 没有取消支持：
QueueUserWorkItem不接受
CancellationToken；
Task.Run可传入并响应取消请求
什么时候非得用 QueueUserWorkItem？基本没有
除非你在维护非常老的 .NET Framework 2.0–3.5 项目（已无官方支持），或者在极低延迟场景下刻意绕过 Task 的少量开销（微秒级，通常不值得）。现代 C# 开发中，它已被明确标记为“遗留 API”，文档也建议迁移到
Task.Run或
Task.Factory.StartNew。 它不支持泛型委托，必须用
WaitCallback（即
Action<object></object>），参数传递要靠 state 对象装箱 没有默认的调度器抽象，无法替换为自定义
TaskScheduler无法与 async/await 语义对齐——你不能在
async方法里安全地“等它结束”，只能靠
ManualResetEvent这类原始同步原语
// ❌ QueueUserWorkItem：状态传递麻烦，无法 await，异常静默崩溃
ThreadPool.QueueUserWorkItem(_ => {
throw new InvalidOperationException("Boom");
}, null);
<p>// ✅ Task.Run：自然融入异步流，异常可捕获，参数直传
var task = Task.Run(() => {
throw new InvalidOperationException("Boom");
});
await task; // 这里才会抛出，且可被 try/catch 捕获</p>Task.Run 和 Task.Factory.StartNew 有啥区别？别乱混用
Task.Run是
Task.Factory.StartNew的安全封装，它强制使用默认调度器（
TaskScheduler.Default），并禁用危险选项（如
LongRunning）。如果你需要长时运行任务或自定义调度，才该用
Task.Factory.StartNew；否则一律用
Task.Run。
Task.Run(action)≡
Task.Factory.StartNew(action, CancellationToken.None, TaskCreationOptions.DenyChildAttach)想跑长任务？用
Task.Factory.StartNew(..., TaskCreationOptions.LongRunning)—— 它会绕过线程池，新建 OS 线程，避免阻塞池中其他短任务 不要用
new Task(...).Start()，容易漏掉 Start 或异常未处理，属于已淘汰模式
性能差异几乎可以忽略，但心智负担差很多
单次调用的开销差距在纳秒级：
Task.Run多一次对象分配和调度器检查，但换来的是可组合性、可观测性和可维护性。高并发下，真正影响性能的是任务本身耗时，不是调度方式。 1000 个短任务用
Task.Runvs
QueueUserWorkItem，吞吐量几乎一致 但用
Task.Run你能轻松写
await Task.WhenAll(tasks)；用
QueueUserWorkItem就得自己维护计数器 +
ManualResetEvent，极易出错 .NET 6+ 中
Task已深度优化，甚至复用内部对象池，开销进一步收窄
真正容易被忽略的点是：Task.Run 不等于“开了新线程”。它只是把工作排进线程池队列，由空闲线程执行——和
QueueUserWorkItem一样共享同一组线程。别以为用了 Task 就能无限并发，线程池仍有并发度限制（默认约 CPU 核心数 × 5），超量任务会排队。
