GitHub Actions矩阵里，一个失败为何有时会取消其他任务

同一组GitHub Actions矩阵任务里，有的组合失败后其他任务继续运行，有的却带来一批取消记录。只看失败任务的系统或语言版本，可能找不到区别。官方指南把失败处理交给两个设置共同解释：矩阵的fail-fast，以及单个任务的continue-on-error。[1]

矩阵用一个任务定义中的变量组合生成多次运行。例如两个操作系统配三个版本，可形成六个组合。这里的“组合”说明各次运行的配置差异，并没有保证它们彼此之间不会受到失败处理策略影响。需要解释取消时，还要看矩阵之外的相关任务属性。

所读页面的Handling failures给出一个混合示例：fail-fast为true，三个普通版本的continue-on-error为false，另加一个实验版本，其continue-on-error为true。原文解释，任何一个continue-on-error为false的任务失败，都会取消该矩阵中正在运行或排队的任务；若失败的是continue-on-error为true的实验任务，其他任务不受这个失败影响。[1]

这个例子的关键，不是把某个版本永久划成实验版，而是看每个组合最后取得的设置。若交接材料只说“矩阵已打开遇错即停”，就会遗漏单个任务对错误的处理差异。本文据此建议同时记录失败组合、它的continue-on-error值，以及该矩阵的fail-fast值，再解释后续取消。

也不能把这里的取消范围扩大成仓库内所有工作流都会停止。文档这段讨论的是矩阵任务的失败处理；某一次其他任务为何取消，仍要结合那次运行的真实日志及配置。看到Cancelled也不是所有被取消组合都已经完成测试并失败的证明：排队任务可能还没有开始运行。

页面另列max-parallel，用来限制矩阵中同时运行的任务数量。它控制并行数量，不能代替上述两个设置解释失败传播。[1] 一组任务只有部分正在运行，可能与并行上限有关；是否最终取消则还需要对应的事件证据，不能从一个状态截图倒推出全部过程。

本文只解读2026年10月9日查阅的GitHub.com官方矩阵指南，页面没有独立发布日期。示例属于官方文档，本文没有触发工作流、修改失败策略或验证实际仓库。将失败与取消分开记录，才能让持续集成报告准确说明哪些组合有结果、哪些仍然缺少测试结果。

参考来源：[1] GitHub Docs，Running variations of jobs in a workflow。