fail-fast 是什么
流水线失败即停的设计：把便宜且致命的检查放最前（编译、语法、lint），失败立即终止后续昂贵环节，节省时间与算力资源；矩阵与并行场景里，快停还能避免其余组合白白烧资源。与之相对的是「收集全貌」模式，调试期需要完整结果时按场景切换，两种策略各有适用面。
基本信息
| 顺序原则 | 由快到慢：lint、单测、集成、打包、部署 |
|---|---|
| GitHub | matrix 的 fail-fast 默认开启，一个组合失败即取消其余 |
| Jenkins | parallel 的 failFast true 同理 |
| 取舍 | 快停省资源；全量报告利于定位问题 |
| 配套 | 快速检查要能给出清晰的失败原因 |
典型使用场景
- 提交验证：编译失败立刻失败，不进入测试与打包。
- 矩阵默认快停：一个组合失败即取消其余组合。
- 并行阶段快停：并行任务中任一失败即整体失败。
- 慢检查后置：端到端与深度扫描放在必要检查之后。
- 成本控制：昂贵步骤只在前置检查全绿后投入。
GitHub matrix 快停
GitHub matrix 快停
strategy:
fail-fast: true
matrix:
node: [20, 22]推荐检查顺序
| 顺序 | 检查 | 理由 |
|---|---|---|
| 1 | 编译与语法 | 最便宜、失败最确定 |
| 2 | 格式与 Lint | 快速、可自动修复 |
| 3 | 单元测试 | 快、覆盖核心逻辑 |
| 4 | 集成与端到端 | 慢、依赖环境 |
| 5 | 扫描与发布 | 昂贵、放最后 |
「先跑全量测试再编译」是常见反模式：语法错误都要等几分钟才暴露。
快停与全貌按场景选：调试期用完整矩阵收集信息，日常提交用快停节省资源。
快速检查要可信：误报频繁的 lint 放最前，只会拖慢每次提交。
被跳过的步骤在日志里要显式标注：快停后哪些检查没跑，交付时才能判断验证覆盖面。
用平均反馈时长衡量效果：快停的价值是缩短从提交到结果的时间，而不是少跑几步的账面数字。
部署与数据迁移这类不可中断步骤不适用快停语义，它们需要自己的顺序与锁保护。