threadpool.queueuserworkitem用于将方法排队交由线程池执行，支持三种重载形式，参数为waitcallback委托或泛型action，需注意闭包陷阱、后台线程终止风险及state参数单对象限制。
直接用 ThreadPool.QueueUserWorkItem 就够了，95% 的“线程池问题”其实不是线程池的问题，而是任务写法、阻塞方式或线程模型误用导致的。
为什么循环提交任务后所有 lambda 都读到同一个值？
这是最常被当成线程池 bug 的现象：for 循环里提交 10 个任务，结果每个都打印出 i == 10。根本原因不是线程池，是闭包捕获了变量 i 的引用，而不是它某次迭代的值。
- 循环结束时
i已是终值（比如 10），所有任务执行时读的都是这个终值 - 修复方式：在循环体内声明局部副本，例如
int taskNumber = i;，然后在 lambda 中用taskNumber - 别依赖
Thread.Sleep或顺序执行来“验证”——线程调度不可控，这种验证本身就有误导性
哪些任务绝对不能往 ThreadPool 里塞？
线程池线程全是后台线程（IsBackground == true），进程退出时直接终止，不等你收尾。以下几类任务会出问题：
- 带
while(true)+Thread.Sleep的轮询逻辑——关程序就断，可能留文件句柄、DB 连接未释放 - 需要优雅关闭的监听器（如消息队列消费者、自定义定时器回调）
- 依赖 STA 线程的 COM 对象（如旧版 Office 自动化）——线程池全是 MTA
- 同步 I/O 或长阻塞操作（如
File.ReadAllBytes大文件、Thread.Sleep(5000)）——会“卡住”线程池线程，拖慢其他任务
这类需求请改用 Task.Run 配合 CancellationToken，或 ASP.NET Core 下的 IHostedService。
什么时候才该调 SetMinThreads？
.NET 6+ 启动时默认最小工作线程通常只有 1 个。高并发短任务突发时（比如 Web API 刚启动就来 200 QPS），线程创建跟不上，任务排队，首波延迟明显——这时才考虑调整。
- 只在应用启动最早期调（如
Main或Program.cs顶部），避免被第三方库覆盖 - 先查现状：
ThreadPool.GetMinThreads(out int worker, out int io)和ThreadPool.GetAvailableThreads(out int availWorker, out int availIo) - 仅当观察到
availWorker长期为 0 且任务持续排队时，才小幅上调最小值（如设为 4 或 8） - 别碰
SetMaxThreads——设太高会导致上下文切换开销飙升；最大值本就是按 CPU 核心数动态扩的（32 核机器默认可能到 1000+）
QueueUserWorkItem 的 state 参数怎么传多个值？
WaitCallback 委托签名固定为 void Method(object state)，所以只能传一个 object。值类型会装箱，但合法。
- 如果要传多个参数，把它们包进一个匿名对象、元组或自定义类，再强制转成
object - 例如：
ThreadPool.QueueUserWorkItem(DoWork, new { Id = 123, Name = "test" }); - 注意：不要在
state中传入非线程安全的对象（如未加锁的List<t></t>），多个任务可能并发访问 - 返回值必须自己处理——线程池不支持直接返回，得靠外部共享变量、
TaskCompletionSource或回调委托
真正容易被忽略的是：线程池不是万能的“异步兜底方案”。它适合短时、无状态、无生命周期依赖的任务。一旦任务开始持有资源、等待外部信号、或需要控制执行节奏，就该换更合适的抽象——比如 Task、Channel、IHostedService 或专用调度器。
