为何部分C#方法（如ThreadPool.QueueUserWorkItem）采用对象传参而非直接传参？

这个问题问得太戳点了！当年刚摸C#线程池的时候我也对着这个设计挠头，其实背后全是.NET早期设计的技术考量和历史约束：

1. 适配.NET 1.0的时代局限性 #

ThreadPool是.NET 1.0就推出的核心API，而泛型是直到.NET 2.0才加入的特性。那时候根本没有Action<T>、Func<TResult>这种带类型参数的委托，只能定义单一签名的WaitCallback：

public delegate void WaitCallback(object state);

为了让这个委托能适配所有可能的方法参数，用object作为参数容器是唯一的通用方案——毕竟.NET里所有类型都继承自object，不管你要传int、字符串还是自定义对象，都能塞进去。

2. 保证线程池调度逻辑的统一性 #

线程池的核心职责是高效调度大量后台任务，如果允许直接传入任意签名的方法，线程池的调度代码就得处理无数种不同的委托类型，复杂度会爆炸。统一用WaitCallback签名后，线程池只需要执行“接收一个object参数、无返回值”的方法，调度逻辑可以完全标准化，不用关心具体任务的参数细节——参数解析的工作交给目标方法自己处理就行。

3. 性能权衡下的可接受代价 #

用object传递值类型会触发装箱操作，这确实有一点点性能开销，但早期.NET团队认为这个代价完全可以接受：线程池的典型场景是处理大量短小的任务，装箱的开销和线程创建、上下文切换的成本比起来，几乎可以忽略不计。而且后来.NET 2.0引入泛型后，也补充了ThreadPool.QueueUserWorkItem(Action<T>, T)这种重载，但为了向后兼容，原始的API一直保留到现在。

4. 闭包语法还未诞生 #

在C# 2.0引入匿名方法和闭包之前，开发者没法轻松捕获外部变量传递给后台方法。那时候要给Multiply(2,3)传参数，只能把2和3打包成一个自定义类/结构体，再塞进object里：

public class MultiplyParams { public int A; public int B; }

ThreadPool.QueueUserWorkItem(new WaitCallback(Multiply), new MultiplyParams { A=2, B=3 });

private void Multiply(object state) {
    var p = (MultiplyParams)state;
    Console.WriteLine(p.A * p.B);
}

现在我们可以用闭包写得更简洁：

ThreadPool.QueueUserWorkItem(_ => Multiply(2, 3));

但这都是后来语法糖带来的便利，早期设计ThreadPool的时候根本没有这个选项。

顺带提一句，现在.NET推荐用Task.Run来替代这种老式的线程池调用，它支持泛型、闭包，API设计更现代：

Task.Run(() => Multiply(2, 3));

内容的提问来源于stack exchange，提问作者J. Doe