构建缓存占用过大是Docker磁盘空间告急的常见原因，需先通过docker builder prune --dry-run确认其为元凶，再按需执行docker builder prune -f等命令安全清理，并配合镜像、日志清理及定时预防措施。
构建缓存占用过大是 docker 磁盘空间告急的常见原因，尤其在 ci/cd 频繁构建、多分支并行开发或基础镜像频繁更新的场景下。它不像运行中容器或数据卷那样“看得见”，却可能悄悄占掉几 gb 甚至十几 gb 空间。关键不是盲目删，而是先确认、再分类、后清理。
确认构建缓存是否真为元凶
别跳过这一步——很多“磁盘满”其实是日志、overlay2 可写层或悬空镜像导致的。先快速验证：
- 运行 docker builder prune --dry-run，查看预估可释放空间（注意单位，常达 GB 级）
- 对比 df -h /var/lib/docker 和 du -sh /var/lib/docker/buildkit（BuildKit 启用时）或 /var/lib/docker/builder（旧版）
- 若
builder prune --dry-run显示回收量远超其他资源（如镜像、卷），基本可锁定构建缓存
安全清理构建缓存的常用方式
构建缓存本身不被任何容器直接依赖，清理风险低，但会影响后续构建速度（首次重建变慢）。推荐按需选择：
Docker Image Puller
下载
使用 Python 脚本下载 Docker 镜像并打包为 tar 文件。用户说“下载镜像”“拉取镜像”“pull xxx”“帮我下载 nginx 镜像”等时触发。支持 SOCKS5 代理直连（推荐）和国内镜像站加速两种模式。
- 仅清未使用缓存：执行 docker builder prune -f，这是最稳妥的日常清理方式，只删当前无任何构建任务引用的缓存层
- 清全部缓存（含可能正被复用的）：用 docker builder prune -a -f，适用于换基础镜像、重构 Dockerfile 或彻底重置环境
- 按时间清理（更精细）：例如 docker builder prune --filter "until=72h" -f，保留最近 3 天的缓存，兼顾空间与效率
配合镜像与日志一并处理
构建缓存常和悬空镜像、容器日志共存。单清缓存可能只解决一半问题：
- 顺手执行 docker image prune -f 清掉无标签中间镜像（dangling images），它们和构建缓存高度重叠
- 检查容器日志：进入 /var/lib/docker/containers/*/*/logs.json，大日志文件可直接清空（
truncate -s 0 logs.json）或配置日志驱动限制大小 - 若空间仍紧张，再考虑 docker system prune -a --volumes -f，但务必确认无重要卷数据
预防下次再爆满
清理是救火，预防才是常态：
- CI/CD 流水线末尾加一行 docker builder prune -f，避免缓存跨构建累积
- 启用 BuildKit 并设置缓存限制：DOCKER_BUILDKIT=1 docker build --cache-from=... --cache-to=...，配合远程缓存减少本地堆积
- 用 cron 定时清理，例如每天凌晨执行：0 3 * * * docker builder prune -f && docker image prune -f
