简介：在C#多线程编程中，Thread与ParameterizedThreadStart默认只接受一个object参数，导致多个参数无法直接传入线程，常常需要额外封装或变通。这份PDF资料正是针对这一痛点，专门整理了两种解决思路。第一种是新建一个运行类，把begin、end等参数定义为类的公有属性，通过类实例启动线程执行方法，整体结构清晰、参数可读性强，缺点是若参数组合多样则需创建多个类；第二种是把参数封装进int[]、List

1. C#向线程中传递多个参数：两个委托签名背后的一次打包博弈

C#向线程中传递多个参数，是每个踏入多线程开发的人都会碰到的第一道坎。Thread 构造函数的委托签名把参数数量死死钉在 0 或 1：ThreadStart 无参，ParameterizedThreadStart 只有单个 object 参数。你有个 method(int begin, int end) 想丢到后台线程跑，直接 new Thread(method) 编译都过不了，绕路方案无非两类：把参数连同执行逻辑封装进一个类，或者把所有参数打包进数组/集合，塞进那个唯一的 object 槽位。下面把两种方案的完整用法、类型处理和踩坑场景过一遍，末尾再给一种基于闭包的现代替代。

2. 方法一：包装类传参——把多个参数收进对象的完整链路与适用边界

2.1 为什么 Thread 只收一个参数：委托签名与线程入口协议

Thread 类从 .NET 1.0 时代就是两个构造函数：Thread(ThreadStart) 和 Thread(ParameterizedThreadStart)。对应的委托声明长这样：

public delegate void ThreadStart(); public delegate void ParameterizedThreadStart(object obj);

委托本质上是一个方法签名模板，Thread 构造函数接收哪种委托，新线程启动时就会按这个签名去调用目标方法。参数个数多一个少一个都编译不过，因为委托的调用列表中只允许出现这一种签名。

这个设计的根子在 CLR 层面的线程入口协议。操作系统创建线程时，入口函数要求是固定签名：一个指针宽度的入参，没有返回值。.NET 为了在这套协议上做托管封装，就把委托设计成了 0 或 1 个引用类型参数——0 对应 ThreadStart，1 对应 ParameterizedThreadStart，恰好覆盖"不需要参数"和"需要传一个对象"两种常见形态。

很多人会问：后来 .NET 有了 Func<T1, T2, TResult> 这类泛型委托，为什么 Thread 不跟着加一个多参数重载？要动的话，Thread 内部包装委托到线程入口的整条链路都得改，涉及执行引擎层面的改动，收益却很小。况且 C# 3.0 之后 Lambda 闭包已经能覆盖绝大多数传参场景，这个问题自然就没有动力去动了。理解这段历史，你才会明白数组方案和包装类方案并不是 C# 的缺陷补偿，而是在既定约束下的两种经典拆解思路。

2.2 完整实现：包装类、属性赋值与 ThreadStart 启动

核心思路一句话：把要传的多个参数变成类的字段或属性，再给类提供一个无参的公开方法作为线程入口，方法内部用字段值去调真正的业务逻辑。

// 包装类：把区间参数收进字段，Run 方法作为线程入口 class RangeTask { private int begin; // 区间起始值 private int end; // 区间结束值（不含） // 属性赋值走 setter，后续可以在赋值时加范围校验 public int Begin { set { begin = value; } } public int End { set { end = value; } } // ThreadStart 委托要求无参方法，字段值在线程启动时已固定 public void Run() { Process(begin, end); } private void Process(int begin, int end) { long sum = 0; for (int i = begin; i < end; i++) { sum += i; } Console.WriteLine($"[{begin}, {end}) 区间累加结果: {sum}"); } }

这段代码里，Begin 和 End 用属性而不是直接暴露公有字段，是为了将来在 setter 里加校验留位置。Run 方法是线程入口，签名必须无参，内部只做一件事：把字段转发给真正干活的 Process 方法。Process 保持私有，参数类型是明确的 int，业务逻辑不受线程机制的干扰。

调用端如下：

RangeTask task = new RangeTask(); task.Begin = 100; task.End = 10000; // ThreadStart 委托包装 task.Run，编译器自动完成方法组到委托的转换 Thread worker = new Thread(new ThreadStart(task.Run)); worker.Start();

new ThreadStart(task.Run) 是显式写法，实际开发中更常见的是直接 new Thread(task.Run)，编译器会自动推断委托类型。两者等价。关键点在于：task.Run 是实例方法，委托对象里保存了目标实例和方法的指针。线程启动后调用 Run 时，this 指的就是那个 task 实例，begin 和 end 字段的值自然就是赋值之后的结果。整个传参过程不涉及类型转换，没有装箱拆箱，也不需要解包，这是包装类方案最大的舒适区。

2.3 状态回传与参数复用：包装类独有的两个优势

有人觉得包装类方案"每换一组参数就要写一个新类"，其实不是。同一业务方法需要不同参数组合时，只需要一个包装类，创建多个实例分别赋值就行。比如同时跑三个区间的累加任务：

RangeTask taskA = new RangeTask { Begin = 1, End = 1000 }; RangeTask taskB = new RangeTask { Begin = 1000, End = 5000 }; RangeTask taskC = new RangeTask { Begin = 5000, End = 10000 }; Thread threadA = new Thread(taskA.Run); Thread threadB = new Thread(taskB.Run); Thread threadC = new Thread(taskC.Run); threadA.Start(); threadB.Start(); threadC.Start(); // Join 等待执行完毕，确保结果可用 threadA.Join(); threadB.Join(); threadC.Join();

每一个实例独立持有自己的 begin 和 end，互不干扰。一组参数天然对应一个任务对象，这个语义在任务拆分和状态追踪的场景下非常好用。

另一个独有的优势是状态回传。线程运行过程中，主线程往往想知道任务的执行结果。数组方案很难做到这点——数组里的值是启动时一次性写入的；包装类可以加一个结果属性：

class RangeTask { private int begin; public int Begin { set { begin = value; } } private int end; public int End { set { end = value; } } public long Result { get; private set; } // 线程结束后主线程可读取 public long? ErrorCode { get; private set; } // 错误码，正常为 null public void Run() { long sum = 0; for (int i = begin; i < end; i++) { sum += i; } Result = sum; // 计算结果写回公共属性 } }

调用线程在 worker.Join() 之后读 task.Result，拿到的就是线程内写入的值。字段和属性是引用类型对象的成员，线程写、主线程读，访问顺序用 Join 做了同步之后不存在竞争问题。数组方案要做同样的事，得把结果再塞回数组的某个槽位，语义上非常别扭。

适用场景可以这样归纳：参数之间逻辑相关、需要反复复用同一套参数结构、需要在线程执行后读取状态或结果。如果只是临时跑一次、参数少且类型笼统，用下面讲的数组/集合方案更轻。

3. 方法二：数组与集合打包——object 槽位里的搬运工与拆箱红线

3.1 打包传参的可行性：object 参数只是个搬运工

ParameterizedThreadStart 接收的那一个 object 参数，本质上是个搬运工。它不关心你塞进来的是什么东西，只要是引用类型就行。数组、集合、自定义类、元组全是引用类型，所以把多个参数放进一个容器，再把容器作为那一个 object 传进去，目标方法里拆开，就突破了"只能传一个参数"的限制。

这条路线有两个前提。第一，参数类型要么相同（用强类型数组），要么都能装箱成 object（用 object[] 或 List

3.2 int[] 强类型数组：同类型参数的打包与解包

对于 method(int begin, int end) 这种同类型参数，int[] 是最直接的容器。先看实现。

// 方法重载：object 版本负责解包，内部再调用原始业务方法 void Process(object state) { // 用 as 做安全转换，失败返回 null，不会抛异常 int[] paramsArray = state as int[]; if (paramsArray == null || paramsArray.Length < 2) { return; // 参数非法，直接退出线程入口 } // 解包成功后调用原始业务方法 Process(paramsArray[0], paramsArray[1]); } // 原始业务方法，签名保持不变 void Process(int begin, int end) { long sum = 0; for (int i = begin; i < end; i++) { sum += i; } Console.WriteLine($"[{begin}, {end}) 区间累加结果: {sum}"); }

这里用了两个重载：Process(object) 是线程入口，Process(int, int) 是原来的业务方法。重载的解析靠参数类型区分，编译器在 Process(paramsArray[0], paramsArray[1]) 这一行看到两个 int 实参，自动选 Process(int, int)，完全隐式完成，不需要任何额外标记。

调用端如下：

int[] args = new int[2] { 100, 10000 }; Thread worker = new Thread(new ParameterizedThreadStart(Process)); worker.Start(args);

worker.Start(args) 把数组引用传给了线程入口，Start 的参数类型就是 object，传数组不需要任何转换。注意这里传的是引用，不是副本。线程入口和主线程共享同一个数组对象，这会在第 4 章展开细讲。

新手最容易在这里写错的是把 Process 直接传给 Thread 构造函数：new Thread(Process)。如果类里只有 Process(object) 这一个重载，编译没问题；要是同时存在 Process() 和 Process(object) 两个重载，编译器会报方法组歧义错误，因为它不知道你指的是哪个重载。遇到这种情况，显式写 new ParameterizedThreadStart(Process) 是最直接的解决方式。

3.3 混合类型与 List

int[] 只能装 int。当参数类型不同，比如一个 int、一个 string、一个 DateTime，就得用 object[] 或者 List

void HandleTask(object state) { object[] items = state as object[]; if (items == null || items.Length < 3) { return; } // 拆箱：前两个是 int，第三个是 string int begin = (int)items[0]; int end = (int)items[1]; string tag = items[2] as string; Console.WriteLine($"任务 [{tag}]: 区间 [{begin}, {end})"); } object[] payload = new object[3]; payload[0] = 100; // int 装箱为 object payload[1] = 10000; // int 装箱为 object payload[2] = "累加任务"; // string 是引用类型，无需装箱 Thread worker = new Thread(new ParameterizedThreadStart(HandleTask)); worker.Start(payload);

拆箱时有一个硬性规则：必须用和装箱时完全相同的类型。装箱时是 int，拆箱就不能写 (short)items[0] 或 (long)items[0]，即使看起来类型兼容，运行时依然会抛 InvalidCastException。这一条坑过不少人，尤其是想把 int 当 long 用的场景。装箱时的类型是 int，拆箱瞬间只认 int，之后再转其他数值类型才算安全。

List

3.4 数组方案的边界：参数规模、可读性与拆箱开销

数组方案最舒服的场景是参数不超过三五个、类型相对固定、任务跑一次不关心回传。参数一多，问题就来了：解包代码里 parameters[0] 到 parameters[7] 依次取值，下标到底对应什么含义，后人读代码全靠注释和记忆。

我曾经在某个模拟项目 X 里见过一串从下标 0 到 11 的解包代码，中间还有一个参数是传错了类型在运行时才暴露的。当时的第一反应就是：这种代码不该用数组方案扛，应该用包装类或者具名类型把语义显式表达出来。

如果参数数量超过五个，或者类型五花八门，我更倾向回到包装类方案，或者用第 5 章要讲的 Lambda 闭包。数组方案的最优区间很窄：参数少、类型整齐、一次性任务。超过这个区间就开始别扭，可读性和类型安全会同时下滑。

4. 多线程传参避坑指南：五种翻车现场与修复方案

4.1 现象：解包强转直接抛 InvalidCastException

线程启动后还没跑到业务逻辑，入口方法第一行就崩了，整个线程直接终止。线程异常又不会自动冒泡到主线程，排查时只能从调试器的线程窗口里看到异常信息。

原因：打包时用的是 int[]，解包端却按 object[] 去转，类型对不上。另一种常见情况是装箱类型不匹配，打包是 int，拆箱写成了 long。

解决：引用类型统一用 as 操作符转型，失败返回 null 而不是抛异常；值类型拆箱前先做类型判断。参考写法：

object[] items = state as object[]; if (items == null || items.Length < 2) return; // is 模式匹配：类型对了才拆箱，双重保险 if (items[0] is int begin && items[1] is int end) { Process(begin, end); }

is 模式匹配是 C# 7.0 之后的语法，写出来比先判断再强转干净得多。

4.2 现象：数组元素被主线程修改，工作线程读到的是脏数据

主线程把 int[] 传给 Start 之后继续跑，循环里改了数组的元素，工作线程读到的值和启动时不一致。批量启动多个线程时尤其严重——同一个数组槽位被反复写入，最后所有线程读到的都是最后一次写入的值。

原因：Start(args) 传的是数组引用，不是深拷贝。主线程和工作线程共享同一个数组对象，任何一侧的修改对另一侧可见。数组方案把这个隐患隐藏得很深，因为看起来像是"值传递"，实际上是引用传递。

解决：定一条规矩——传给线程的参数对象在线程启动后视为只读。确实需要复用数组的，Start 之前先复制一份：

int[] original = new int[2] { 100, 10000 }; int[] args = (int[])original.Clone(); // 浅拷贝已足够，元素是值类型 Thread worker = new Thread(new ParameterizedThreadStart(Process)); worker.Start(args);

Clone 对值类型数组是逐元素复制的，没问题。但如果是引用类型数组，Clone 只复制引用不复制对象本身，需要深拷贝时得自己遍历。这一点最容易踩空。

4.3 现象：for 循环里启动的线程，全都拿到同一个循环变量

循环内每轮启动一个线程，Lambda 表达式里直接用了循环变量 i，跑起来发现所有线程输出的 i 都是循环结束后的终值。

原因：C# 的 for 循环变量是单例变量，Lambda 捕获的是变量本身而不是当前迭代的快照。循环结束后 i 停在终值，所有闭包读到的都是这个最终值。C# 5.0 之后 foreach 的迭代变量改成了每轮新建，但 for 没有这个待遇。

解决：循环体第一行声明局部变量做拷贝：

for (int i = 0; i < 10; i++) { int current = i; // 每次迭代新建一个变量 Thread worker = new Thread(() => Process(current, current + 100)); worker.Start(); }

闭包捕获的是每次迭代新建的 current，各线程各拿各的，互不干扰。这个坑从 .NET Framework 时代坑到 .NET 8，属于多线程传参里最经典的血泪经验。包装类方案天然免疫这个问题，因为每个实例的字段是独立存储，不存在共享变量的可能。

4.4 现象：包装类属性没校验，Begin 比 End 大，结果全错

包装类跑出来结果总是对不上，甚至直接是 0。排查半天发现 Begin 和 End 赋反了，或者 End 传成了负数。赋值过程发生在主线程，没有任何一道关卡拦住非法值。

原因：属性 setter 只做了赋值，没有范围校验。非法值一路流进 Process 方法，运算是否正确完全取决于业务代码自身有没有兜底。

解决：在 setter 里加校验，让非法参数在主线程赋值时立刻暴露：

public int Begin { set { if (value < 0) { throw new ArgumentOutOfRangeException(nameof(value), "起始值不能为负数"); } begin = value; } }

校验抛异常的位置在主线程，堆栈一打出来就知道是哪一行赋值出了问题。批量赋值场景里如果不想抛异常，也可以把非法值记录到状态属性，等线程启动后统一判断，但那种方式排查成本更高，不如直接在源头拦。

4.5 现象：线程内异常静默，任务悄悄失败，主线程毫无感知

线程入口方法里抛了异常，主线程完全无感，程序继续跑，但这个任务已经失败了。日志里什么都没有，任务结果缺失，只能靠数据对不上反推。

原因：线程不是主线程调用栈的一部分，异常不会沿调用链向上传播。CLR 的默认行为是触发 AppDomain.UnhandledException 事件，不订阅这个事件就等于黑匣子。

解决：线程入口方法顶层务必包 try-catch，异常写进日志或者存到包装类的错误属性：

class RangeTask { public Exception Error { get; private set; } public void Run() { try { Process(begin, end); } catch (Exception ex) { Error = ex; // 主线程 Join 之后读取 // 同时在日志里记录 ex.ToString() } } }

主线程在 Join 之后检查 task.Error 是否为 null，就能明确区分成功和失败。这也是包装类方案相比数组方案的一个硬优势：数组方案想做同样的错误回传，得额外定义一个结果容器类，绕了一圈又回到了包装类的思路上。

5. 进阶：Lambda 闭包与 Task.Run 的传参新姿势

5.1 Lambda 闭包：编译器替你生成包装类

C# 3.0 引入 Lambda 表达式之后，多参数传线程有了第三种解法：

int begin = 100; int end = 10000; Thread worker = new Thread(() => Process(begin, end)); worker.Start();

看起来 Thread 构造函数还是收 ThreadStart 委托，但 () => Process(begin, end) 这个 Lambda 会被编译器转换成一个闭包类，begin 和 end 变成闭包类的字段，Process 调用发生在闭包类的 Invoke 方法里。本质上就是方法一的包装类，只是类由编译器自动生成，名字形如某个程序集内部类。理解了这一点，你就会明白为什么闭包方案在传多个参数时如此干净——你省掉了手写包装类的全部工作。

闭包生命周期要注意：只要 worker 线程还活着，闭包对象就不会被回收。如果 begin 和 end 是外部方法的局部变量，而且后续被修改，线程读取到的是修改后的值，和数组引用传递是同一个坑。需要快照时，在 Lambda 外面加一层拷贝：

int beginSnapshot = begin; // 局部拷贝，闭包捕获这个副本 int endSnapshot = end; Thread worker = new Thread(() => Process(beginSnapshot, endSnapshot));

5.2 Task.Run 与 async/await：更现代的参数传递风格

用 Task.Run 跑后台任务时，参数直接作为闭包变量捕获，连 Start 都省了：

Task task = Task.Run(() => Process(100, 10000));

Task.Run 接收 Action 或 Func ，Lambda 里可以引用任意数量的外部变量，线程调度的内部细节由任务调度器封装。要拿返回值更方便：

Task<long> task = Task.Run(() => ComputeSum(100, 10000)); long result = await task; // 异步等待，直接拿到结果

这两种写法在 .NET 4.5 之后的项目里已经成了主流。它们和经典 Thread 方案的差距在于：资源开销更低、配合 async/await 做异步编排更自然、取消和异常传播都有标准机制。闭包方案和 Task.Run 方案的正确性都依赖同一个前提——理解闭包捕获的是变量而非当时的快照。

5.3 三种方案选型对照与个人习惯

从做并行区间累加模拟项目那次踩过闭包变量坑之后，我每次写多线程传参都会先问自己三个问题：参数的生命周期多长？线程启动后参数会不会变？需不需要把结果传回主线程？三个问题回答完，方案基本就定了。数组方案救急最快，包装类方案最稳，Lambda 闭包方案最省事，但各有边界。希望帮到你。

本文还有配套的精品资源，点击获取