关键不是“开了DinD就快”，而是解决其默认无层缓存的瓶颈；需启用BuildKit、内联缓存、多阶段构建、overlay2驱动、资源限制及镜像加速源来协同提速。
在 GitLab CI 中用 Docker-in-Docker（DinD）加速镜像构建，关键不是“开了 DinD 就快”，而是要解决它默认无层缓存这个核心瓶颈。DinD 每次启动都是干净的 Docker 引擎实例，基础镜像得重拉、构建层无法复用——这才是慢的根源。真正提速靠的是主动引入缓存机制和构建策略优化。
启用 BuildKit 并配置内联缓存
BuildKit 是现代 Docker 构建引擎，支持更智能的缓存传递和并行处理。必须显式启用，并配合内联缓存将缓存信息写入镜像本身，供下次构建直接复用：
- 在
.gitlab-ci.yml中设置变量：DOCKER_BUILDKIT: "1"和BUILDKIT_PROGRESS: plain -
before_script中先拉取上一次构建的镜像（作为缓存源）：docker pull $CI_REGISTRY_IMAGE:latest || true -
script中使用--cache-from和--build-arg BUILDKIT_INLINE_CACHE=1：docker build --cache-from $CI_REGISTRY_IMAGE:latest --build-arg BUILDKIT_INLINE_CACHE=1 -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .
合理设计多阶段 Dockerfile
把构建环境和运行环境彻底分离，让大部分构建层（如依赖下载、编译）集中在前几个阶段，而最终镜像只包含运行时必需内容。这样即使应用代码频繁变更，也不会导致整个镜像重建：
- 第一阶段（
builder）用完整工具链镜像（如golang:1.21或maven:3.8-jdk-11），完成依赖解析与编译 - 第二阶段（
runtime）用极简镜像（如alpine:latest或openjdk:11-jre-slim），仅COPY --from=builder复制产物 - 确保
COPY指令顺序合理：先拷pom.xml或package.json，再执行安装命令，让依赖层独立缓存
配置高效存储驱动与资源限制
DinD 容器自身的性能直接影响构建速度。默认的 vfs 驱动效率低，必须显式指定高性能驱动，并防止资源争抢：
- 在
variables中添加：DOCKER_DRIVER: overlay2（Linux 环境下推荐） - 为 DinD 服务加上资源约束，避免 OOM 或抢占 Runner 资源：
services:- name: docker:27.4.1-dindresources:limits:memory: 4Gicpu: "2" - 若 Runner 运行在 Kubernetes 上，还需确认节点已启用
overlay2支持且内核版本 ≥ 4.0
搭配私有镜像仓库与国内加速源
基础镜像拉取慢是构建卡顿的常见原因。不能只靠缓存，还要从源头缩短网络耗时：
- 在 DinD 容器内配置国内镜像加速器：通过挂载或环境变量注入
registry-mirrors，例如阿里云镜像地址https://<xxx>.mirror.aliyuncs.com</xxx> - 优先使用企业私有 Registry 替代 Docker Hub；所有基础镜像（如
ubuntu:22.04、node:18）提前同步到内部仓库，构建时直接拉取本地地址 - 在
before_script中预热常用基础镜像：docker pull my-registry/internal/ubuntu:22.04，避免构建时首次拉取阻塞
