ThreadPool.QueueUserWorkItem适用于轻量、短时、无状态后台任务，如日志记录；需避免闭包捕获、阻塞操作、长期运行及STA需求；优先用Task.Run或IHostedService替代，而非盲目调优线程池参数。直接用 ThreadPool.QueueUserWorkItem 是最常用也最安全的起点绝大多数后台轻量任务，比如日志记录、异步通知、简单计算，不需要自己造轮子，ThreadPool.QueueUserWorkItem 就够用。它背后是 .NET 全局线程池，开销极低，且自动复用线程。常见错误现象：for (int i = 0; i Console.WriteLine(i)); } 输出全是 5 —— 这是典型的闭包捕获变量问题，不是线程池的问题，而是 lambda 捕获了循环变量 i 的引用。正确做法：在循环内声明局部副本，如 int taskNumber = i;，再在 lambda 中使用 taskNumberWaitCallback 委托签名固定为 void Method(object state)，传入的 state 参数必须是 object 类型，不能直接传值类型（会装箱，但可接受）不推荐在其中执行长时间阻塞操作（如 Thread.Sleep(5000) 或同步 I/O），否则会“吃掉”线程池线程，拖慢其他任务什么时候该调 SetMinThreads 和 GetMaxThreads默认线程池大小是运行时自适应的，但在高并发短任务场景（如 Web API 突发请求、批量文件扫描），刚启动时线程创建跟不上，任务排队，造成首波延迟。这时才需要干预。性能影响明显：设得太小，任务排队；设得太大，内存和上下文切换开销上升，反而降低吞吐。.NET 6+ 默认最小工作线程数通常是 1，最大则随 CPU 核心数动态调整（例如 32 核机器可能默认最大 1000+）。查当前配置：ThreadPool.GetMaxThreads(out int worker, out int io) 和 ThreadPool.GetMinThreads(out int worker, out int io)仅在应用启动早期（如 Main 或 Program.cs 最开头）谨慎调用 ThreadPool.SetMinThreads(4, 4)，避免后续被其他库覆盖不要盲目设 SetMaxThreads，除非你明确观察到 ThreadPool.GetAvailableThreads 长期为 0 且任务持续排队别把 ThreadPool 当作长期运行服务的载体线程池线程都是后台线程（IsBackground == true），进程退出时它们会被强制终止，不会等待任务完成。所以它不适合跑定时器、消息监听、或需要优雅关闭的守护逻辑。 Tellers AI Tellers是一款自动视频编辑工具，可以将文本、文章或故事转换为视频。