Docker构建缓存通过分层哈希复用机制加速镜像生成，但指令变更、基础镜像更新等会导致缓存失效；需合理组织Dockerfile、使用.dockerignore，并搭配docker builder prune、image prune -a、system prune -a --volumes --force等命令按需清理，推荐在CI末尾或定时任务中自动化执行。
构建缓存是 Docker 加速镜像生成的核心机制，用得好能大幅缩短 CI/CD 时间，用不好反而会堆积大量无效层、拖慢系统甚至引发磁盘爆满。关键不在“要不要用”，而在于“怎么用得准、清得稳”。
理解缓存怎么生效
Docker 构建时，每条 Dockerfile 指令（如 FROM、RUN、COPY）都会生成一个只读层，并基于内容哈希唯一标识。只要基础镜像相同、当前指令及之前所有指令完全一致，就复用已有层——这就是缓存命中。
- COPY 或 ADD 的文件内容变了 → 当前层及之后全部重建
- 修改了 RUN 指令顺序或参数 → 后续层全部失效
- 注释变动、空格增减也被视为指令变更 → 缓存不命中
- 基础镜像 tag 更新（如 ubuntu:22.04 → ubuntu:22.04.1）→ 所有依赖该层的缓存失效
让缓存更高效的做法
不是所有写法都利于缓存复用。合理组织 Dockerfile 是低成本提效的关键：
- 把变动少的内容（如基础环境安装）放在前面，变动频繁的（如源码 COPY）放后面
- 合并多个 RUN 命令，减少层数（例如：RUN apt-get update && apt-get install -y curl && rm -rf /var/lib/apt/lists/*）
- 用 .dockerignore 排除不需要参与构建的文件（如 node_modules、.git、日志），避免上下文变大导致哈希不一致
- 优先选用固定 tag 的基础镜像（如 alpine:3.20 而非 latest），增强可重复性
清理哪些缓存？用什么命令？
不同命令作用范围不同，误用可能删掉正在运行的服务依赖。按需选择：
- docker builder prune：只清构建缓存（BuildKit 缓存），不影响镜像或容器，最安全常用
- docker image prune：删悬空镜像（dangling images，即无标签且未被任何容器引用的中间层）
- docker image prune -a：删所有未被容器引用的镜像（含带标签但闲置的），慎用
- docker system prune -a --volumes --force：清空所有未使用资源（镜像、容器、网络、卷、构建缓存），适合 CI 流水线末尾或定期维护
执行前可用 docker system df 查看各类型资源占用，用 docker builder prune --dry-run 预览将删内容。
自动化清理建议
人工清理容易遗漏，尤其在 CI 环境中高频构建时。推荐嵌入标准流程：
- CI 脚本最后加一句：
docker-compose down --rmi local && docker builder prune -f（停服务 + 清本地构建镜像 + 清构建缓存） - Linux 上设定时任务，每天凌晨清理：
0 3 * * * /usr/bin/docker builder prune -f && /usr/bin/docker image prune -f - 若使用 BuildKit，可在构建时加
--progress=plain观察缓存命中情况，便于诊断问题
