用途：在 GitLab 仓库内编排持续集成与交付流水线，适合自托管与企业 GitOps 场景、容器镜像与 Helm 包集成、多项目与下游流水线、以及基于 monorepo 路径动态生成的父子流水线。
主要能力：以声明式 .gitlab-ci.yml 定义 stages、缓存与 artifacts；使用 rules 与 rules:changes 控制任务触发；通过 reports:junit 与 reports:coverage_report 在合并请求中展示测试与覆盖率；使用 GitLab Container Registry、Package Registry 与 Dependency Proxy；支持受保护环境与 when: manual 手动部署门禁。
使用方式：在仓库根目录编写 .gitlab-ci.yml，示例结构为 stages 定义 build、test，任务指定 image、script、artifacts 与 needs。例如 build-job 使用 node:20 执行 npm ci 与 npm run build 并产出 dist/，test-job 依赖 build-job 执行 npm test。容器构建可用 docker:27-cli 配合 docker:27-dind 服务，登录 $CI_REGISTRY 后 build 与 push。
适用场景：需要跨仓库协调构建、按目录变更过滤任务、在合并请求中查看测试洞察、以及为生产发布设置人工审批的企业流水线。
限制与注意：资料未提供具体收费、价格与平台支持范围。建议避免使用已弃用的 only/except，改用 rules；不要在 .gitlab-ci.yml 中存放明文密码，应使用 Masked 与 Protected 变量；共享环境避免特权 Docker-in-Docker，可考虑 Kaniko 无根构建。常见问题包括 only 与 rules 混用导致 YAML 无效、任务超出 runner 超时、下游任务找不到 artifacts（需声明 dependencies）。