小粒度任务 vs 大粒度任务：优缺点对比、适用场景、性能影响
每次聊到 CI 任务拆分，团队里总会有两拨人吵起来。有人喜欢把任务切得特别细，恨不得一个步骤一个 job；有人觉得分太细显得啰嗦，干脆一个 build 脚本跑到底。说实话，我也曾经在这两者之间反复横跳。
今天咱们就掰扯清楚：小粒度和大粒度到底有什么不同，什么时候该用哪个。我会结合自己踩过的坑来讲，希望能让你少走点弯路。
1. 先看对比：小粒度 vs 大粒度
直接上表格，把核心差异摆出来。你别急着记，看完后面案例再回来看这张表会更明白。
| 维度 | 小粒度任务 | 大粒度任务 |
|---|---|---|
| 任务拆分单位 | 单个操作（如 lint、单元测试） | 多个操作打包（如完整构建流程） |
| 并发执行 | 可并行，独立失败不阻塞 | 串行执行，任一失败全部回滚 |
| 失败定位 | 精准到具体步骤，日志清晰 | 需要逐段排查，定位难题 |
| 依赖管理 | 需要明确上下游，配置复杂 | 依赖隐含在脚本内部，配置简单 |
| 流水线总耗时 | 可能略有增加（调度开销） | 通常更快（无调度间隙） |
| 可重用性 | 高，可被其他流水线调用 | 低，通常定制化强 |
嗯，从表里能看出来，没有的好坏。关键在于你当前在什么场景下。
2. 小粒度任务的优势与陷阱
我个人习惯在项目早期就做小粒度拆分。为什么呢？两个原因。
- 快速失败与精准反馈：我记得有一次在 CI 里把 lint、单元测试、集成测试分成了三个独立 job。代码提交后 lint 失败了，集成测试根本不会启动。开发者看到失败提示的那一刻就知道是代码规范问题，十多秒就修完了。要是放在一个大 job 里，他得等五六分钟才发现是 lint 报错，中间这段时间全浪费了。
- 并行加速：你把单元测试拆成 10 个并行的 job，每个跑一部分测试用例，总耗时从原来的 30 分钟降到 8 分钟——我见过最夸张的一个项目就这样搞的。但要注意，不是所有任务都能随便并行。比如编译型语言，生成中间产物可能要先完成编译，然后才能分片测试。这时候就要用流水线产物传递。
关键指标：小粒度任务的并行度不是越高越好。单 job 耗时如果低于 10 秒，调度开销就开始占主导了。最佳范围通常在 30 秒到 5 分钟之间。
不过小粒度也有坑。我曾在某个 Node.js 项目里把 job 拆得过细，每个 job 都要重新安装依赖，结果 CI 总时间反而比原来大 job 多了 40%。这就像你去超市买东西，每买一件就跑一趟收银台——效率肯定低。
3. 大粒度任务的适用场景
那什么时候该用大粒度？我遇到过这几个典型情况。
- 快速原型验证阶段：项目还在想法阶段，一天改几十次代码。这时候搞细粒度拆分纯属给自己添堵。直接一个 build 脚本搞定，等代码稳定了再拆分。
- 静态资源构建：比如 Webpack 打包、压缩 CSS、合并图片这类任务，本身就是完整的处理链，拆开了反而因为临时文件传递增加复杂度。我通常会把这些放在一个 job 里，加几个阶段（stages）做解耦就够了。
- 跨团队的统一部署流水线：当你的 CI 最终产物是某个包或者镜像时，大粒度任务可以避免一些团队之间的依赖混乱。举个例子，A 团队改了一个公共模块，B 团队构建时引用了旧版本，如果流水线粒度太大，定位起来非常麻烦。但这种情况其实更应该用依赖锁定和版本管理来解决，不是单纯用任务大小能搞定的。
我的做法：先用大粒度跑通全流程，再逐步拆解耗时最长的 job。优先拆那些失败频率高、定位困难的任务。你想想看，如果 lint 从来没失败过，那它单独拆出来意义不大。相反，集成测试老挂，就得单独拎出来，还得进一步拆。
4. 性能影响：调度开销与资源利用
很多人觉得小粒度一定比大粒度慢，其实不全对。我们来算笔账。
假设你有一个编译任务，需要 5 分钟。把它拆成「安装依赖→编译→单元测试」三个 job。每个 job 之间有一到两秒的调度延迟，CI runner 的启动时间大概 3 秒。这样总耗时 = 3 + (依赖安装 2 分钟 + 3) + (编译 3 分钟 + 3) + (单元测试 1 分钟 + 3)。算下来约 6 分 12 秒。而一个大 job 跑完全部只需要 5 分钟（依赖安装、编译、测试串行在一个容器里完成）。看起来大粒度快了 1 分多钟。
但等一下，如果你的项目有频繁变更，小粒度可以针对性地只重跑失败的那一步——比如只重跑单元测试，而不是整个 build。这时候累积收益就反超了。我有个项目，CI 日运行 200 次，切到小粒度后平均每次耗时反而从 12 分钟降到了 9 分钟，因为重跑的概率降低了 30%。
曾经我掉进过一个坑：为了减少调度开销，我把所有测试脚本硬塞进一个 job，结果内存不够，测试直接 OOM。所以大粒度要考虑单次资源配额，小粒度反而可以通过并行把负载分散到多个 agent 上。你想想看，一个 runner 跑一整包测试 vs 十个 runner 各跑一小包，后者资源更可控。
5. 决策框架：一张图帮你选
下面是我梳理的一张决策流程图。你可以照着它判断当前阶段应该用哪种粒度。特别注意，这不全是二选一的问题——很多流水线是混合的，比如用大粒度做初始编译，再用小粒度做并行测试。
6. 实践建议与避坑指南
写到最后，给你几个我亲身验证过的建议。
- 从单次构建耗时入手：如果单次 CI 跑完超过 15 分钟，优先拆那些最慢的 job。我以前有个 Java 项目，集成测试要跑 40 分钟，拆成 8 个并行 job 后降到 6 分钟。收益立竿见影。
- 注意缓存和依赖共享：小粒度任务如果共用同一个编译产物，一定要用流水线 artifact 或者缓存机制。我曾经忘记配置依赖传递，结果每个 job 都重新编译了一遍源码，CI 时间翻了三倍。那叫一个惨。
- 不要为了拆分而拆分：如果任务本身只有 1 分钟，拆成 6 份每份 10 秒，调度时间比执行时间还长。这种时候保持大粒度就好。
- 我喜欢混合式：用大粒度做初始的编译、代码检查等强依赖任务，然后用小粒度做测试、部署等可并行任务。既保证了配置简洁，又发挥了并行优势。你可以试试看。
曾经碰到的典型问题：一个微服务项目，我们把每个服务的构建拆成独立 job。看起来很美，但后来发现服务之间有共享的 protobuf 文件，每次改协议就要等所有 job 重新编译完 proto。这时候小粒度反而成了负担。解决方案是把公共 proto 编译提成一个前置 job，后续服务 job 只拉取编译好的产物。你看，小粒度也需要合理的层级划分。
任务粒度说到底是个权衡。没有银弹，最适合你当前阶段和团队习惯的才是最好的。记住一点：先跑通，再优化，别一上来就套完美方案。好了，今天就聊到这儿。去分析一下你的流水线吧。