核心是用好stages、rules、needs和include四个机制：stages定义阶段顺序与边界；rules按条件精准触发作业；needs实现跨阶段依赖与并行加速；include拆分配置、复用模板、管理多环境。
写复杂流水线不是堆功能，而是分层组织、按需触发、精准控制。核心是用好 stages、rules、needs 和 include 这四个机制，让逻辑清晰、复用性强、维护成本低。
用 stages 定义执行顺序和阶段边界
流水线不是线性脚本，而是有明确阶段划分的工作流。stages 决定所有作业的全局执行顺序，同一 stage 内的作业默认并行，不同 stage 严格串行。
- 把构建、测试、部署、发布等职责拆成独立 stage，比如：
stages: [build, test, deploy, release] - 一个 stage 可以包含多个作业（例如多个测试套件），它们会并发运行；下一个 stage 必须等上一 stage 所有作业成功后才启动
- stage 名称不能重复，也不建议用空格或特殊字符，保持简洁如
build、integration-test
用 rules 控制作业是否运行及何时运行
比旧版 only/except 更灵活，rules 支持条件判断、变量引用、变更路径匹配，适合复杂分支策略和环境区分。
- 常见写法：
rules: - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'表示只在 MR 流水线中运行 - 结合文件变更：
- changes: ["src/**/*", "pom.xml"]表示只在这些路径改动时触发构建 - 组合使用：
- if: '$CI_COMMIT_TAG' - when: always表示打 tag 时必跑，且不依赖前序结果 - 注意：rules 是“全或无”，一旦某条规则匹配且
when不为never，该作业就会加入流水线
用 needs 实现跨 stage 的作业依赖与并行加速
默认 stage 间强顺序，但 needs 允许跳过 stage 等待，让作业在前置依赖就绪后立刻执行，提升整体效率。
-
needs: [build_frontend]表示当前作业只等待build_frontend完成，不等整个buildstage 其他作业 - 支持跨 stage 依赖，比如测试作业可直接
needs: [build_backend, build_frontend]，两个构建完成后立即启动测试 - 配合
needs: {job: xxx, artifacts: true}可自动下载指定作业产出的 artifacts - 注意：被依赖的作业必须已定义且在同一 .gitlab-ci.yml 或已通过
include加载
用 include 拆分配置、复用模板、管理多环境
单个 .gitlab-ci.yml 超过 200 行就该拆了。include 支持本地文件、项目内路径、甚至远程仓库引用，是模块化关键。
- 基础结构：
include: - local: '/templates/base.yml'引入同仓库下的模板 - 复用作业定义：把通用的 build、test、scan 作业写成模板（用
.job-template命名），再用extends继承 - 环境差异化：为 dev/staging/prod 分别准备
/env/dev.yml、/env/prod.yml，通过变量动态 include - 父子流水线：父流水线用
trigger: include: 'child/.gitlab-ci.yml'启动子流水线，适合微服务或多仓库协同
不复杂但容易忽略：YAML 缩进必须用空格，不能用 tab；每个作业必须有 script；全局 default 可统一设置 image、before_script 等，减少重复；验证配置用 GitLab 自带的 CI Lint 工具，比手动推代码试错高效得多。
