GitLab CI 处理复杂构建依赖的核心是用 needs 显式声明 DAG 式作业依赖，配合 artifacts: false 控制仅等待不下载产物，dependencies 仅决定产物获取范围而不影响执行顺序。
GitLab CI 处理复杂构建依赖关系，核心在于精准控制作业执行顺序、产物传递范围和跨阶段/跨项目上下文。它不靠“阶段顺序”硬约束，而是用 needs 主动声明依赖，配合 artifacts 和 dependencies 精细管理产物流向。
用 needs 显式定义 DAG 式依赖
needs 是处理复杂依赖的首选机制，支持有向无环图（DAG）结构，打破传统 stage 串行限制：
- 一个作业可同时等待多个上游作业完成，无论它们是否同 stage
- 支持
artifacts: false，表示仅需等待完成，不下载产物（节省带宽和时间） - 可混合指定 job 名与 artifacts 策略，例如：
needs:<br> - { job: build-backend, artifacts: true }<br> - { job: build-frontend, artifacts: false }<br> - { job: lint, artifacts: false } - 避免隐式依赖，所有依赖必须显式写出，提升可读性和可维护性
按需控制 artifacts 下载：dependencies 不等于 needs
dependencies 只控制“哪些产物要被当前作业下载”，不决定执行顺序：
- 若未配置 dependencies，作业默认不获取任何上游产物
- 即使某作业在 needs 中被引用，若未列入 dependencies 列表，其 artifacts 也不会自动下载
- 常见组合：
needs: [build]+dependencies: [build]表示“等 build 完成且取它的产物”；needs: [build]+dependencies: []表示“只等它完成，不要产物” - 适合测试作业需验证构建结果但无需源码或二进制文件的场景
跨项目或父子流水线依赖需额外配置
当依赖来自其他仓库或触发的下游流水线时，基础 needs 不生效，需结合 trigger 或 pipeline triggers：
- 使用
trigger关键字启动下游流水线，并设置strategy: depend让当前作业等待下游成功 - 下游流水线生成的 artifacts 需通过
artifacts:paths明确声明，上游才能通过 API 或共享存储间接获取 - 极狐 GitLab（GitLab SaaS 付费版）支持
needs:project直接跨项目引用作业，但社区版需借助制品仓库（如 Nexus、S3）中转 - 父子流水线中，子流水线可通过
variables: { PARENT_PIPELINE_ID: $CI_PIPELINE_ID }回传上下文，实现状态联动
大产物与多模块场景下的实用策略
面对多模块、大体积构建产物（如 5GB 工具链），应避免全量传递：
- 将公共依赖（如交叉编译工具链）挂载为 Runner 的只读 volume，而非打包进镜像或作为 artifacts 传输
- 各模块独立构建，用 needs 协调关键节点（如“全部模块编译完成”后才运行集成测试），但不强制传递全部产物
- 对必须共享的中间产物（如 proto 编译后的 go 文件），统一输出到固定路径并启用
artifacts:expire_in防止堆积 - 用
rules动态控制是否运行某依赖作业，例如仅当$MODULE_A_CHANGED == "true"时才触发 module-a 的构建和发布
