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()），让线程归还给池。
![c# byte[] 和 string 如何转换](/d/file/efpub/2026/02-21/smalle64be0ee112a3dda19ba9dbe2727c2f81771666614.jpg "c# byte[] 和 string 如何转换")
