ThreadPool 是底层线程复用机制，Task 默认运行其上；直接调用 QueueUserWorkItem 缺乏 Task 的异常传播、await、延续等能力，且易引发异常丢失、竞态等问题，多数场景应优先使用 Task.Run()。
ThreadPool 是底层线程复用机制，Task 默认跑在 ThreadPool 上
绝大多数 Task.Run()、Task.Factory.StartNew()（未指定 TaskScheduler 时）创建的后台任务，实际都由 ThreadPool 提供线程执行。这不是巧合，而是 .NET 的默认调度策略：避免频繁创建/销毁线程，把工作项排队交给池中空闲线程处理。
这意味着你写 Task.Run(() => DoWork())，背后大概率调用了 ThreadPool.QueueUserWorkItem()；但反过来，直接用 ThreadPool.QueueUserWorkItem() 创建的工作项，**不会自动获得 Task 的生命周期管理、异常传播、延续（.ContinueWith()）、await 支持等能力**。
Task 不等于线程，也不绑定线程生命周期
Task 是一个异步操作的抽象，它可能：
- 在
ThreadPool线程上同步执行（如Task.CompletedTask） - 在
ThreadPool线程上异步执行（最常见） - 在 UI 线程（通过
TaskScheduler.FromCurrentSynchronizationContext()） - 甚至根本不占用线程（如纯 I/O 操作，依赖完成端口，无托管线程参与）
而 ThreadPool 中的线程是真实 OS 线程，会被复用、可能被回收、受 ThreadPool.SetMinThreads()/SetMaxThreads() 控制。一个 Task 启动后，无法保证它始终运行在同一个线程上（尤其跨 await 后可能回到不同上下文）。
手动调用 ThreadPool.QueueUserWorkItem 的典型陷阱
直接使用 ThreadPool.QueueUserWorkItem() 时，容易忽略以下问题：
- 异常不会自动抛到主线程或被捕获——未处理的异常会直接终止进程（.NET Framework）或静默丢弃（.NET Core+，但会触发
UnobservedTaskException事件） - 无法用
await等待完成，也不能链式调用.ContinueWith() - 无法获取返回值，只能靠闭包或外部变量传递结果，易引发竞态
- 没有内置取消支持，需手动检查
CancellationToken并配合ThrowIfCancellationRequested()
例如，下面这段代码看起来能“异步执行”，但异常会丢失，也无法等待：
ThreadPool.QueueUserWorkItem(_ =>
{
throw new InvalidOperationException("Boom");
});
什么时候该用 ThreadPool，什么时候该用 Task？
绝大多数场景下，优先用 Task（尤其是 Task.Run()）：
- 需要
await、.Result、.Wait()或异常传播时 - 要组合多个异步操作（
Task.WhenAll()、Task.WhenAny()） - 需要结构化取消（
cancellationToken参数） - 逻辑上代表“一个可等待的异步工作单元”
只有极少数低层场景才直接碰 ThreadPool：
- 高性能服务器中，自己实现轻量级任务队列，绕过
Task对象分配开销（注意：.NET 6+ 的ValueTask和对象池已大幅缓解此问题） - 需要精确控制线程池大小且不希望
Task调度器干扰（比如某些实时性敏感的后台轮询） - 与旧版 API 交互，必须传
WaitCallback委托
真正容易被忽略的是：即使你用了 Task.Run()，如果里面执行的是长时间阻塞操作（如 Thread.Sleep(5000) 或同步 I/O），依然会浪费 ThreadPool 线程——此时应改用真正的异步 API（await Task.Delay()、await stream.ReadAsync()），让线程归还给池。
