needs 可绕过 stage 顺序限制，实现按作业依赖而非阶段先后自由调度；其本质是显式声明依赖关系，要求被依赖作业真实存在、未被 rules 过滤，且支持 artifacts 传递与 rules 组合使用。
直接用 needs 就能绕过 stage 顺序限制，让作业按依赖关系而非阶段先后自由调度，核心是把“等前一整个 stage 结束”变成“只等它真正需要的那几个作业完成”。
needs 的本质：显式声明依赖，不是阶段对齐
默认情况下，GitLab 流水线严格按 stages 顺序执行：build 全部成功 → test 才启动 → deploy 才开始。但 needs 让你跳过这个排队逻辑，只要目标作业已就绪，哪怕它属于更后面的 stage，也能立刻运行。
- 一个
test阶段的作业可以needs: ["build-frontend"]，而不用等build-backend完成 -
deploy-staging可以在test-e2e还没跑完时，只要build-image和security-scan完成就启动 - 多个 stage 的作业可以同时运行，只要它们各自的
needs条件满足
正确写法与关键约束
needs 不是随意指向，必须确保被依赖的作业真实存在、可被触发，且不被 rules/only 过滤掉。
- 写法示例：
needs: ["build-ui", "build-api"]或needs: [{job: "build-ui", artifacts: true}]（带产物传递） - 被依赖作业不能因
rules判定为 skip，否则流水线解析失败，报 YAML error - 默认最多引用 10 个作业（
ci_dag_limit_needs功能标志启用），超限需联系管理员调整 - 不支持跨 pipeline 引用，只能在同一 .gitlab-ci.yml 定义的作业间使用
典型非阻塞场景实战
当构建和测试模块化后，needs 能显著缩短端到端时长。
-
并行构建 + 按需测试：UI 和 API 分别构建；UI 测试只需等
build-ui，API 测试只需等build-api，两者完全不互相等待 -
安全扫描不拖慢部署：部署 staging 环境只需要镜像构建成功，不必等安全扫描结果；但 production 部署可设
needs: ["build-image", "security-scan"]作强校验 -
快速反馈先行：代码检查（lint）和单元测试可设为
needs: []，立即启动，无需卡在 build 阶段之后
搭配 rules 和 artifacts 提升灵活性
needs 常和 rules、artifacts 组合使用，实现更精细的控制。
- 用
rules控制哪些分支/事件才启用某作业，再用needs精准拉取它产出的 artifact -
needs: [{job: "build", artifacts: true}]表示该作业会自动下载build作业生成的产物（如 jar 包、dist 目录） - 配合
dependencies可进一步限定只传部分产物，避免冗余传输
