缓存命中需指令及上下文完全一致，关键四点：稳定内容前置、避免过早全量copy、固定基础镜像tag、用.dockerignore排除干扰；多阶段构建分离编译与运行环境，提升缓存复用率并减小体积；清理应区分场景，优先用docker builder prune等精准命令。

合理利用缓存能大幅缩短构建时间，而定期清理又能防止磁盘被无效层占满。关键在于理解“什么会命中”和“什么该删掉”。

让缓存真正起作用的 4 个实操要点

缓存不是自动生效的，得按规则组织 Dockerfile：

• 把稳定内容放前面：比如先 COPY go.mod 和 go.sum，再 RUN go mod download；这样依赖没变时，这一步就直接复用，不用重下包
• 避免过早 COPY 整个代码目录：写成 COPY . . 意味着只要改一行代码，后续所有层（包括依赖安装）都会失效；应拆开，只复制必要文件
• 固定基础镜像 tag：用 FROM node:18.19.0 而不是 FROM node:18 或 FROM node:latest，防止基础层意外更新导致全量重建
• 用 .dockerignore 排除干扰项：把 node_modules/、dist/、.git、日志等加进去，避免它们进构建上下文，触发无谓的缓存失效

多阶段构建是缓存+体积双优化利器

它把构建和运行分离，既提升缓存复用率，又产出极简镜像：

Docker Encyclopedia

Docker 文档优先工作流：针对 Docker 特定问题、故障排除、命令规划、镜像/构建、容器/运行时操作及 Compose 等

下载

• 第一阶段（builder）专注编译：装 Go、复制源码、执行 go build，这一阶段的缓存可长期复用，哪怕你每天改代码，只要依赖不变，下载和编译步骤都不用重跑
• 第二阶段（runtime）只拿产物：用 alpine 或 distroless 镜像，仅 COPY --from=builder 二进制文件，不带任何编译工具或源码
• 两个阶段各自独立缓存，互不影响；最终镜像体积通常能压到原来的 1/5 甚至更小

哪些缓存该清？用对命令才不伤系统

清理不是越狠越好，要区分对象和影响范围：

• docker image prune：只删“悬空镜像”（dangling），即没标签、也没被任何容器引用的中间层，安全，可日常执行
• docker builder prune：清理 BuildKit 构建缓存（含未被引用的构建阶段输出），CI 流水线里建议每次构建后加这步
• docker system prune -f：一键清空所有未使用资源（镜像、容器、网络、构建缓存），适合本地开发环境定期维护，但会删掉所有已停止的容器记录
• 查空间占用用 docker system df，重点关注 “Build Cache” 行的 RECLAIMABLE 值，决定是否值得清理

CI/CD 中让缓存持续有效的技巧

流水线环境容易因并行构建或分支切换导致缓存失灵，可主动干预：

• 启用 BuildKit：DOCKER_BUILDKIT=1 docker build，支持更细粒度缓存和并发构建
• 跨构建复用缓存：docker build --cache-from=registry.example.com/myapp:latest，从远程镜像拉取缓存层（需提前推送）
• 在 GitHub Actions 等平台中，用 actions/cache 缓存 ~/.npm 或 ~/.m2 目录，绕过容器内重复下载
• 为不同分支设置独立缓存键（如基于 git commit hash 或 branch name），避免 feature 分支污染 main 分支的缓存