搞异步编程这么多年，我一直在跟 .NET 的任务并行库（TPL）打交道。最初接触 TPL 的时候，处理并行任务之间的先后顺序最让我头疼，尤其是“一批任务全部跑完，再做下一件事”这种常见的场景。当时我用得最多的就是Task.Factory.ContinueWhenAll。这个 API 虽然看起来不起眼，但它代表了 TPL 延续模型里很核心的一环：把一组任务的结果汇合点，变成一个全新的任务。很多老项目里大量使用了这种写法，你如果看不懂它，读代码会非常吃力。这篇文章我就把这个 API 从头到尾拆开讲清楚，包括方法签名、调度细节、实际案例，还有我踩过的一些坑。
我先把结论放在前面：如果是新写的 async/await 代码，绝大多数情况下用Task.WhenAll会更好，代码也更简洁；但如果你在做延续式任务链、处理回调式 TPL 管道，或者需要维护旧代码，Task.Factory.ContinueWhenAll仍然是绕不开的基础。理解它，不是为了让你把它当成首选，而是为了让你在遇到这类代码时，能准确判断它的行为，不至于被“延续不执行”“异常没抛出来”之类的问题卡住。
1. 从任务到延续：ContinueWhenAll 到底解决了什么问题
1.1 TPL 的“任务接力”模型
TPL 的核心抽象是Task，表示一个未来会完成的操作。这个抽象本身不难理解，难的是把多个任务串起来。你可能有三个下载任务、两个计算任务，它们各自独立启动，但你希望它们在全部结束之后再进入下一步。最朴素的做法是逐个Wait()，然后按顺序处理结果。这当然可行，但问题是：当你调用Wait()的时候，当前线程就阻塞了。在异步或并行场景里，阻塞意味着浪费线程资源，也可能造成线程饥饿。
TPL 给出的方案是“延续”。所谓延续，就是给一个任务挂上后续动作，前一个任务完成时，后续动作会自动启动。ContinueWith是单任务延续的入口，而ContinueWhenAll是“多任务合流”的入口。简单说，Task.Factory.ContinueWhenAll(tasks, action)做的事情是：等待tasks数组里的所有任务都处于完成状态，然后启动新的延续任务，在延续任务里执行action。
这个设计思路有点像接力赛：你把接力棒分别交给几个选手，等所有人都到达终点，下一棒的选手才开始跑。各位选手到达的先后顺序不重要，重要的是“全部到达”这个聚合条件。
1.2 ContinueWhenAll、ContinueWith、ContinueWhenAny 的定位区别
很多初学者把ContinueWith和ContinueWhenAll搞混。它们在代码形式上非常像，但语义差别很大。
ContinueWith：针对单个任务，一个前序任务对应一个后续任务。它处理的是“一件事情做完之后做什么”。ContinueWhenAll：针对多个任务，所有前序任务都完成后才执行后续任务。它处理的是“多件事都做完之后做什么”。ContinueWhenAny：同样针对多个任务，但只要有任意一个前序任务完成，后续任务就会启动。它处理的是“最先完成的那件事触发什么”。
这三个方法共同构成了 TPL 延续机制的基础。ContinueWhenAll最适合“汇合”场景，也就是并行分支最后要合并结果的场景。举个具体的例子：你要从三个不同的服务拉取配置，三个请求可以同时发出去，但最终配置文件要合并后写入磁盘。这种情况，ContinueWhenAll就是很自然的表达方式。
1.3 有了 Task.WhenAll，为什么还要了解 ContinueWhenAll
说实话，现在写 async/await 代码，我几乎不会主动去用ContinueWhenAll。Task.WhenAll可谓它的“异步替代版”。当你写await Task.WhenAll(tasks)时，编译器会帮你处理后续逻辑，代码就像同步代码一样自然，异常也能通过 try/catch 捕获，可读性好太多了。
但这不代表ContinueWhenAll没有价值。第一，老代码里大量存在这种延续式写法，尤其是一些历史遗留的批处理框架、工作流引擎、自定义任务调度组件。第二，在某些高级场景里，你可能需要把延续动作本身作为独立任务去调度、取消、监控。这时候ContinueWhenAll返回的Task对象，就比 async/await 的隐式状态机更容易在运行时被“钩住”。第三，ContinueWhenAll和ContinueWith系列在 TPL 内部的实现机制是相通的，理解它有助于理解整个延续模型。
所以我的态度很明确：新代码优先 async/await，但读懂ContinueWhenAll是基本功。接下来我把它的 API 细节和底层行为拆开看。
2. 方法签名与调度细节：先把 API 看透再写代码
2.1 全部重载与参数含义
Task.Factory.ContinueWhenAll不是只有一个简单版本，它有一组重载。归纳起来主要分两类：非泛型版本和泛型版本。
非泛型版本的核心形式：
public Task ContinueWhenAll( Task[] tasks, Action<Task[]> continuationAction )它的含义是：等待tasks全部完成，然后执行continuationAction。传给continuationAction的参数，就是先前那一整个tasks数组。这看起来有点奇怪，为什么回调参数不是单个Task，而是整个数组？因为延续的任务本身就是“汇总节点”，你需要检查每个前序任务的结果状态，自然要把数组传进来。
泛型版本多针对Task<TResult>：
public Task<TResult> ContinueWhenAll<TAntecedentResult, TResult>( Task<TAntecedentResult>[] tasks, Func<Task<TAntecedentResult>[], TResult> continuationFunction )这个版本返回一个泛型任务，表示延续动作的最终结果。还有带CancellationToken、TaskContinuationOptions、TaskScheduler的完整重载：
public Task<TResult> ContinueWhenAll<TAntecedentResult, TResult>( Task<TAntecedentResult>[] tasks, Func<Task<TAntecedentResult>[], TResult> continuationFunction, CancellationToken cancellationToken, TaskContinuationOptions continuationOptions, TaskScheduler scheduler )参数多了之后，行为就会变得复杂。cancellationToken不是用来取消前序任务的，而是用来取消延续任务本身的。continuationOptions决定延续在什么条件下启动。scheduler决定延续任务被安排到哪个调度器上执行。这些参数组合起来，是很多诡异问题的高发区。
| 参数 | 作用 | 常见失误 |
|---|---|---|
Task[] tasks | 待等待的前序任务集合 | 传入空数组或混入未启动的任务 |
continuationAction | 全部完成后的回调 | 在回调里直接访问.Result触发异常 |
cancellationToken | 取消延续任务本身 | 误以为它能取消前序任务 |
continuationOptions | 设置延续触发条件 | 使用互斥选项导致运行时异常 |
scheduler | 指定延续的调度器 | 未指定时默认调度行为不直观 |
2.2 TaskScheduler 和 TaskContinuationOptions 的行为细节
先说TaskContinuationOptions。最常见的值是None，也就是默认行为。这时候，只要前序任务全部完成，无论它们是成功、失败还是被取消，延续任务都会执行。你可能会问：既然如此，那前序任务抛出的异常去哪了？
这里是新手最容易迷糊的地方：TPL 延续默认不会自动传播前序任务的异常。如果你想在延续里拿到异常，要么先通过Task.WaitAll(tasks)去触发AggregateException，要么遍历tasks逐个检查Status和Exception。还要注意，TaskContinuationOptions.OnlyOnRanToCompletion和NotOnRanToCompletion这类选项，是基于“前序任务最终处于什么状态”来决定是否启动延续的。当你在代码里同时指定了NotOnCanceled和OnlyOnCanceled，就会抛出ArgumentOutOfRangeException，因为这两个条件互斥。这是很典型的运行时错误。
再说TaskScheduler。TPL 的延续默认会使用当时的TaskScheduler.Current，如果你在线程池线程上调用，它一般就是线程池调度器。但如果你在某个自定义调度器上下文里调用，延续就可能跳到那个上下文执行。这个行为对新手来说非常反直觉，因为很多人以为延续一定会在线程池线程上运行。想要稳定预期，最简单的办法就是显式传入TaskScheduler.Default。这样延续任务基本确定在线程池线程上执行，避免被当前上下文“劫持”。如果你希望延续在特定同步上下文里跑，可以传TaskScheduler.FromCurrentSynchronizationContext()，不过对于典型的服务器应用，我宁愿直接用显式的调度器或继续用 async/await。
2.3 内部机制简析：信号量式的完成计数
理解ContinueWhenAll的底层行为，我习惯把它想象成一个“倒计数信号量”。TPL 内部会为这组前序任务创建一个包装的延续代理，每个前序任务完成时，内部计数就减一。当计数归零，也就是所有任务都完成时，才触发真正的延续回调。为什么这样设计？因为每个任务完成的时间不固定，直接轮询所有任务状态太浪费资源，倒计数方式只需每个任务完成时做一次判断。
这个机制也解释了为什么ExecuteSynchronously选项存在。默认情况下，最后一个前序任务完成时，TPL 会把延续任务排队到目标调度器上执行，这个排队过程有开销。加了ExecuteSynchronously后，延续可能会直接在上一个完成任务的线程上同步执行。优点是省了调度开销，缺点是执行线程不确定，而且如果延续里写了耗时操作，你会意想不到地拖慢最后一个前序任务所在线程。我的经验是：只有延续动作极短时才用ExecuteSynchronously，否则宁可多花一次调度开销，也不要让延续阻塞未知线程。
3. 实操：三类最典型的 ContinueWhenAll 场景
3.1 场景一：聚合多个并行加载任务的结果
假设你有三个数据源，需要并行读取，然后把读取结果合并成一个文件。这是典型的“并行读取、汇合写入”场景。先看一版基于ContinueWhenAll的写法：
var dataSources = new[] { "https://example.com/data/1.txt", "https://example.com/data/2.txt", "https://example.com/data/3.txt" }; var loadTasks = dataSources .Select(url => Task.Run(() => LoadData(url))) .ToArray(); var mergeTask = Task.Factory.ContinueWhenAll( loadTasks, completedTasks => { var buffer = new StringBuilder(); foreach (var task in completedTasks) { // 不能直接 task.Result，因为可能有失败任务 if (task.Status == TaskStatus.RanToCompletion) { buffer.AppendLine(task.Result); } else { buffer.AppendLine($"[{task.Status}]"); } } File.WriteAllText("merged.txt", buffer.ToString()); }, CancellationToken.None, TaskContinuationOptions.OnlyOnRanToCompletion, TaskScheduler.Default ); // 等合并任务完成后检查结果 mergeTask.Wait();这段代码里，我特意加上了OnlyOnRanToCompletion，表示只有所有加载任务都成功完成时，才执行合并。因为在“合并三个文件”的业务中，任何一个数据源失败，最终合并文件就是残缺的，不如不合并。如果选择None，那合并逻辑就必须自己判断每个任务的状态，否则很容易在task.Result上崩掉。
这里要注意一个细节：Task.Run(() => LoadData(url))返回的是Task<string>数组，ContinueWhenAll会推断泛型参数，所以你可以在回调里拿到带泛型结果的任务数组去访问.Result。当你只是把任务数组声明为Task[]，结果就会被擦除成非泛型Task，访问结果就比较麻烦了。
3.2 场景二：并行计算后合并输出
再看一个 CPU 密集型场景：把一个大数组拆成三段，每段分别求和，最后合并总和。用ContinueWhenAll可以写成这样：
var segments = new[] { new[] { 1, 2, 3, 4, 5 }, new[] { 6, 7, 8, 9, 10 }, new[] { 11, 12, 13, 14, 15 } }; var sumTasks = segments .Select(seg => Task.Run(() => SumArray(seg))) .ToArray(); var totalTask = Task.Factory.ContinueWhenAll( sumTasks, completed => completed.Sum(task => task.Result), CancellationToken.None, TaskContinuationOptions.OnlyOnRanToCompletion, TaskScheduler.Default ); Console.WriteLine("总和: " + totalTask.Result);这里的ContinueWhenAll泛型版本返回Task<int>，你可以直接获取合并结果。将这个写法与Task.WhenAll对比：
var sums = await Task.WhenAll(sumTasks); var total = sums.Sum();后者明显简洁。前者更大的意义在于：你可以把“计算总和”这个动作本身作为一个可等待的Task对象往下传，甚至在它之后继续挂新的ContinueWith。如果你是在构建一个流水线式的任务链，每个节点都需要统一处理，那么ContinueWhenAll这种“动作即任务”的表达方式，在动态构建链条时会比较顺手。
3.3 场景三：老代码 Task 链中的延续接力
我有一次维护老项目，里面有一段代码用ContinueWith实现了多阶段处理管道：任务 A 完成后，启动任务 B 和任务 C 并行，等 B 和 C 都完成后再启动 D。代码结构大概是这样的：
var bAndC = Task.Factory.ContinueWhenAll( new[] { taskB, taskC }, completed => D(completed) ); var final = bAndC.ContinueWith(bc => Finalize(bc.Result));在这种老式任务链里，ContinueWhenAll承担着“分支汇合点”的作用。你想用 async/await 重写，当然可以，但改动范围会很大。如果你能读懂这种链式结构，维护起来心理压力会小很多。你只需要知道：bAndC这个任务，只有在taskB和taskC都完成时才会启动；而final则是在bAndC完成后继续执行。它本质上就是一个基于回调的分步流水线。
3.4 执行这段代码前必须知道的几个约定
写ContinueWhenAll时有几个约定，我想放在实操部分强调，因为踩过坑，印象太深了。
第一，前序任务数组必须已经处于被调度的状态。如果你把一堆new Task(...)尚未调度的任务传进去，这些任务永远不启动，延续也就永远不会触发。最常见的正确做法是先用Task.Run或Task.Factory.StartNew把任务启动，再把它们作为数组传进去。
第二，延续回调里面不要直接做阻塞等待。延续回调本身就运行在一个后台线程上，你在这个回调里再调用.Wait()，如果线程池线程数不够，很容易把线程池资源耗尽。正确做法是让回调本身“小且快”，或者通过 async/await 配合WhenAll处理更复杂的等待逻辑。
第三，注意延续返回的任务需要被观察。ContinueWhenAll返回的也是一个Task，如果它的回调里抛出异常，而这个任务又没有被人等待或检查Exception，异常可能被吞掉或触发TaskScheduler.UnobservedTaskException。我一直默认给延续任务挂一个观察逻辑，至少要在合适的地方Wait()或者ContinueWith(t => { var _ = t.Exception; })一下。
4. 踩坑实录：ContinueWhenAll 的经典问题与排查方法
4.1 问题一：延续不执行
这是群里被问得最多的问题。代码逻辑看着没问题，但ContinueWhenAll里的回调就是没跑。排查顺序我一般是这样的：
- 先确认所有前序任务都已经启动。
Task.Run返回的任务已经是热任务，但如果你手动new Task后忘了Start()，任务永远处于Created状态，延续永远等不到完成信号。 - 再确认前序任务没有因异常或取消而进入非预期状态。
ContinueWhenAll默认是“全部完成就继续”，这里的“完成”包含RanToCompletion、Faulted、Canceled。但如果你写了OnlyOnRanToCompletion，只要有任何一个任务失败，延续就不会执行。这未必是 bug，可能是选项和业务意图不匹配。 - 最后检查延续任务本身是否被取消。如果传入了已经取消的
CancellationToken，延续任务会直接进入取消状态，回调不执行，表面上看起来就像“延续没跑”。这种情况代码里通常不会有明显输出，需要看Task.Status才能发现问题。
我实际见过一个案例：同事把CancellationTokenSource在别处提前Cancel()了，然后一直怀疑是ContinueWhenAll的 bug。检查顺序对了，马上就能定位。
4.2 问题二：在延续里访问 Result 抛出 AggregateException
延续回调里经常会写task.Result，因为大家觉得“既然所有任务都完成了，拿结果应该没问题”。这种直觉在OnlyOnRanToCompletion场景下是对的，但如果用了默认None，就要小心了。
当某个前序任务以Faulted状态结束时，它内部记录的AggregateException不会自动抛出来，可你一旦访问task.Result，这个任务会重新抛出它的异常。结果就是，你的延续回调会在一瞬间炸掉，而且因为异常发生在延续任务内部，你甚至不一定能在原地捕获到。排查的时候很容易绕弯路。
我的建议是：如果前序任务存在失败可能，延续回调里先把task.Status检查一遍，再决定是否访问Result。不要抱有侥幸心理。你可能会觉得OnlyOnRanToCompletion能规避这个问题，但注意，OnlyOnRanToCompletion是“所有前序任务都成功才执行”，假如你只想让延续在某些子任务失败时也跑，那还是得靠状态检查。
4.3 问题三：阻塞等待造成死锁或线程饥饿
这是和 TPL 相关的经典问题。很多人写了延续之后，会立刻在同一个线程里调用continuationTask.Wait()等结果。如果襟翼某些线程相关条件，很容易死锁或线程饥饿。
具体场景是这样：线程池线程有限，你把一批长任务都扔进线程池，然后自己又Wait()在其中一个线程上。线程池发现线程不够，会调度新线程，但调度过程有延迟。如果任务里也有阻塞等待，新线程又被占住，整个系统就陷入饥饿状态。ContinueWhenAll根本得不到执行机会。
我通常的处理原则是：能用 async/await 就绝不用.Wait()，因为await不会阻塞线程，而是释放线程让其他任务执行。如果确实需要同步等待，最好限定超时时间，例如Wait(TimeSpan.FromSeconds(5))，然后判断返回值，不要无限期等下去。
4.4 问题四：空数组与取消行为的边界
ContinueWhenAll传空数组的情况，你可能以为会立即返回一个已完成的任务。我刚开始也是这么想的，实际行为却出乎意料。TPL 的实现中，空数组会被解释为“所有前序任务都已完成”的边界情况，但延续任务真正执行与否，还受continuationOptions和取消令牌影响。虽然从语义上可以把空数组视为“全部完成”，但不同重载在组合OnlyOnRanToCompletion和取消令牌时的行为可能不一致，最好不要依赖这种边界条件。
我的建议非常简单：在上层显式拦截空数组。如果前序任务列表为空，等于这个合流点没有意义，直接跳过或返回一个已完成任务，而不是测试关于空的边界行为。
4.5 问题排查速查表
| 现象 | 可能原因 | 排查动作 |
|---|---|---|
| 延续回调完全不执行 | 前序任务未启动 | 检查任务是否已Start()或来自Task.Run |
| 延续回调不执行但任务状态 Faulted | 启用了OnlyOnRanToCompletion | 查看前序任务异常，调整选项 |
| 回调执行后程序崩溃 | 访问了Faulted任务的.Result | 改用状态检查，或使用Exception属性 |
| 等了很久没返回 | 当前线程被阻塞，延续任务线程饥饿 | 改用await，避免同步等待 |
| 传入空数组结果不确定 | 边界条件被依赖 | 显式处理空列表 |
| 取消令牌触发后回调仍执行 | 取消令牌只作用于延续而非前序任务 | 检查参数语义，重新设计取消时机 |
5. 一些个人建议：这个 API 该怎么用
5.1 现代写法的选择顺序
如果让我从零开始写新功能，我的选择顺序是这样的：优先用 async/await 加Task.WhenAll，这是可读性和异常处理最好的方案。只有当我要面对老代码的延续链、动态构建任务链节点、或者确实需要在一个延续任务上继续挂多个后续动作时，我才会用ContinueWhenAll。
为什么我不提倡新代码里大量使用它？因为延续式代码的异常流实在不透明。前序任务失败、延续选项控制、回调里异常状态，这些在 async/await 里都能用 try/catch 压掉，但在延续模型里，要操心的事情太多。可如果已经是延续式结构，强行半路改成 async/await，也会让代码风格很割裂。我的习惯是：在一段代码里保持同一种并发风格，不要混着来，除非只是为了某个特定节点做隔离。
5.2 沿用旧代码的适配策略
老代码里的ContinueWhenAll往往不是孤立出现的，它可能连着ContinueWith、ContinueWhenAny串成一长串。你要修改这部分逻辑时，不要急着整体重写，先画清楚任务依赖图：每个任务的起点是谁，合流点是谁，分支点是谁。ContinueWhenAll就是合流点，ContinueWhenAny是抢先点，ContinueWith是接力点。画明白之后，你才能确定每个任务的异常会流向哪里。
我自己的实践是，对遗漏异常的任务链加一层全局观察任务：
var wrapped = continuationTask.ContinueWith( t => { if (t.IsFaulted) { Log(t.Exception); } }, CancellationToken.None, TaskContinuationOptions.OnlyOnFaulted, TaskScheduler.Default );这样即使延续内部出了问题，也至少有一个观察任务把异常记录下来，不会让异常悄无声息地丢失。
5.3 把延续任务当作观察点来用
最后分享一个小技巧。ContinueWhenAll返回的延续任务本身，可以当作一个“观察点”挂到其他逻辑上。比如你要监控一组后台任务的完成情况，可以写：
var monitor = Task.Factory.ContinueWhenAll( workerTasks, completed => { var successCount = completed.Count(t => t.Status == TaskStatus.RanToCompletion); var failureList = completed .Where(t => t.Status == TaskStatus.Faulted) .Select(t => t.Exception) .ToList(); Report(successCount, failureList); }, CancellationToken.None, TaskContinuationOptions.ExecuteSynchronously, TaskScheduler.Default );这里我用了ExecuteSynchronously，因为回调逻辑很轻量：数一下成功数量，汇总一下异常列表。这么写的好处是，主流程完全不用关心这组任务的内部细节，只需要在一个全局监控任务里统一收集状态。等到你想重构的时候，观察点又变成批量读取结果的地方。这种“把合流点做成监控钩子”的思路，在处理后台批处理任务时非常实用。
我在实际项目里见过很多ContinueWhenAll的误用，也见过把它用得行云流水的代码。它就像一把老式扳手，新项目里你可能更喜欢棘轮扳手的爽快感，但当你在现场遇到那颗老螺母时，老式扳手是唯一能卡住位置的工具。理解它、会用它是基本功，至于什么时候掏出来用，那就看你对整个任务依赖图的理解了。
