清理和禁用 Docker 构建缓存需区分构建中间层缓存（如 BuildKit cache）与镜像层：前者存于 /var/lib/docker/buildkit/cache，不显示在 docker images 中，须用 docker builder prune 清理；后者是已生成镜像，用 docker image prune 处理。禁用缓存用 --no-cache 参数强制重建。
清理和禁用 docker 镜像构建缓存，核心在于区分“构建过程中产生的中间层缓存”（buildkit cache 或传统 build cache）和“已生成的镜像层”。它们存储位置不同、触发方式不同、清理命令也不同。直接删镜像（docker image prune）并不能清掉构建缓存，这点常被忽略。
禁用构建缓存：强制重新构建每一层
适用于验证代码变更是否生效、排查缓存导致的构建异常，或确保完全基于最新依赖生成镜像。
-
单次禁用：在构建时加
--no-cache参数docker build --no-cache -t myapp:latest . -
多阶段构建中局部禁用：对某一个构建阶段跳过缓存，可用
--cache-from=显式指定来源，或配合--target控制范围 -
CI/CD 中推荐做法：在关键发布流水线中固定使用
--no-cache，避免因本地缓存残留导致环境不一致
清理构建缓存：删除未被引用的中间层快照
构建缓存不是镜像，不显示在 docker images 列表里，而是存在 /var/lib/docker/buildkit/cache（BuildKit 启用时）或 overlay2 的临时层中。中断构建（如 Ctrl+C）、反复重试、参数微调都容易堆积。
-
清理未使用的构建缓存：
docker builder prune -f
这是最常用、最安全的清理方式，只删当前无任何构建任务引用的缓存层 -
清理全部构建缓存（含正在使用的？不，仅“未使用”的）：
docker builder prune -a -f
注意：它不会删掉正在被某个构建过程锁定的缓存，所以仍是安全的 -
查看缓存占用情况（预估空间释放量）：
docker builder prune --dry-run
输出类似：Total: 2.4GB (1234 layers)，便于评估是否值得清理
识别并清理残留的悬空镜像与中间层
虽然不属于“构建缓存”，但很多用户误以为是缓存——其实是构建过程中生成的、带 <none>:<none> 标签的中间镜像。它们占空间、干扰判断，应一并处理。
-
只删悬空镜像（低风险）：
docker image prune -f -
删所有未被容器引用的镜像（含带标签的旧版本）：
docker image prune -a -f
比如你拉了redis:7.0并运行过容器，后来删了容器但没删镜像，它就属于这类 -
组合清理更精准：
docker image prune -a -f --filter "reference=myapp:*" --filter "until=168h"
表示只删过去 7 天内、名称匹配myapp:前缀的所有未用镜像
长期治理：从源头减少缓存积压
光靠定期清理是被动应对。真正降低维护成本，得靠配置+规范。
-
限制构建缓存大小：编辑
/etc/docker/daemon.json，加入："builder": {"gc": {"defaultKeepStorage": "3g"}}
重启 Docker 后，BuildKit 会自动淘汰最久未用的缓存，防止无限增长 -
启用日志轮转：同样在
daemon.json中配置日志驱动参数，避免单个容器日志文件涨到数 GB 占满磁盘 - 在 Dockerfile 中优化指令顺序：把变动少的部分（如基础镜像、系统依赖安装）写在前面，频繁修改的源码复制放后面，提升缓存命中率，自然减少无效重建
