GitLab Runner 构建加速核心是重建缓存可延续性：用 BuildKit+Registry 远程缓存替代本地层缓存，优化 Dockerfile 指令顺序与 .dockerignore，DinD 下预热基础镜像，多阶段构建精准隔离变更。
GitLab Runner 默认使用临时环境，每次作业都重建容器，Docker 层缓存天然丢失。要真正解决缓存失效、实现构建加速，核心不是“找缓存”，而是**重建缓存的可延续性**——让不同作业之间能共享、复用和感知变化。
用 BuildKit + Registry 远程缓存替代本地层缓存
原生 Docker 构建在 Runner 中无法保留层缓存，因为容器一结束，镜像层就销毁。BuildKit 的远程缓存机制能绕过这个限制：
- 启用
DOCKER_BUILDKIT=1和buildx，配置远程缓存后端为 GitLab 容器 Registry（支持 inline 或 registry 模式） - 在
.gitlab-ci.yml中添加缓存导出参数：--cache-to type=registry,ref=$CI_REGISTRY_IMAGE:build-cache,mode=max --cache-from type=registry,ref=$CI_REGISTRY_IMAGE:build-cache - 这样每次构建会把层哈希推送到 Registry，下次作业拉取时自动命中，不依赖宿主机或 Runner 容器生命周期
重构 Dockerfile 让缓存“稳住”不变的部分
缓存失效大多源于指令顺序错乱或上下文污染，不是缓存没开，是缓存“不敢用”：
- 按变更频率从低到高排列：先
FROM（固定 tag，如node:18.19.0-alpine），再COPY package*.json，接着RUN npm ci，最后COPY . . - 加
.dockerignore排除node_modules、.git、logs/、dist/等——这些文件哪怕没被COPY，也会参与构建上下文哈希计算，一改全崩 - 避免
COPY . /app放太前；Node.js 项目中，package-lock.json变更才重装依赖，源码改一百次也不影响npm ci层
在 DinD 场景下复用基础镜像层
Docker-in-Docker（DinD）服务每次启动新 Docker daemon，连 docker pull 都要重下基础镜像。提速关键在于预热与复用：
- 在
before_script中提前拉取高频基础镜像：docker pull $BASE_IMAGE || true（如node:18.19.0-alpine） - 利用
cache: key: ${CI_JOB_NAME}缓存/var/lib/docker目录（仅限 privileged runner 且磁盘空间充足时） - 更稳妥的做法是：用
buildx构建时指定--load+--cache-from，跳过 DinD 内部 daemon，直接走 BuildKit 缓存链
分阶段控制缓存粒度，尤其用好多阶段构建
多阶段本身不加速，但配合缓存策略能精准隔离变更影响范围：
- 把编译、测试、打包拆成独立 stage，每个 stage 的输入尽量窄（例如只 COPY
src/和package.json） - 构建阶段用
AS builder，运行阶段用FROM alpine:latest AS runtime，再用COPY --from=builder复制产物——这样即使builderstage 因代码变更重建，runtime层仍可复用旧缓存 - 对私有依赖或 SSH 拉取场景，启用
RUN --mount=type=ssh，避免把密钥写进镜像或破坏缓存稳定性
