GitLab CI 通过合理利用 Docker 分层缓存、多阶段构建、BuildKit 远程缓存及固定基础镜像标签，可显著提升构建速度；关键在于稳定缓存层、将易变操作后置、分阶段隔离缓存并显式复用。

靠合理利用 Docker 的分层缓存机制，GitLab CI 构建流水线能明显提速，尤其在频繁提交、小范围变更的场景下效果更突出。关键不是“用不用缓存”，而是让每一层尽可能稳定、复用率高。

把易变内容往后放

Dockerfile 指令按顺序逐层构建，一旦某层失效（比如源码变了），它之后所有层都会重建。所以要把变动频繁的操作尽量放在后面：

• COPY . /app 这类复制整个代码目录的指令，别放在 RUN apt-get install 之前——否则改一行代码，连依赖都要重装
• 先 COPY go.mod 和 go.sum，RUN go mod download；再 COPY . .；这样依赖不变时，下载步骤直接命中缓存
• 前端项目可先 COPY package.json + yarn.lock，再 yarn install，最后 COPY 其余源码

多阶段构建配合阶段级缓存

多阶段不只是为了减体积，更是为了隔离缓存边界。每个阶段独立缓存，互不影响：

GitHub AI Trends Reporter

生成 GitHub AI 趋势项目报告，以格式化文本排行榜呈现。抓取每日、每周或每月的 AI/ML/LLM 高星项目并渲染...

下载

• 构建阶段（builder）专注编译，用 golang:1.21 或 node:18 等带工具链的镜像
• 运行阶段（runtime）只 COPY 编译产物，用 alpine 或 distroless 镜像，不包含任何构建工具
• CI 中可通过 --cache-from=registry.example.com/myapp:builder-latest 显式拉取前一阶段缓存镜像

启用 BuildKit 并配置远程缓存

默认 Docker 构建器对缓存支持有限，BuildKit 是现代构建引擎，支持更精准的缓存匹配和并发优化：

• 在 .gitlab-ci.yml 中加环境变量：DOCKER_BUILDKIT=1 和 BUILDKIT_PROGRESS=plain
• 使用 --cache-to type=registry,ref=registry.example.com/myapp/cache:latest 推送中间层
• 下次构建加 --cache-from type=registry,ref=registry.example.com/myapp/cache:latest 拉取复用
• 私有 Registry 需开启 blob mount 支持，或用 GitLab Container Registry 直接对接

固定基础镜像标签，避免隐性失效

FROM ubuntu:latest 或 node:alpine 这类浮动标签，每次拉取可能拿到不同镜像，导致第一层就失效：

• 统一用精确标签：ubuntu:22.04、node:18.17-alpine3.18
• 若用自建基础镜像，确保其构建也启用缓存并打固定语义化版本号
• 可在 CI 脚本中加校验：docker inspect $BASE_IMAGE | jq -r '.[0].Id'，防止意外更新破坏缓存链