直接清理构建缓存是最有效的应对方式，尤其当频繁 docker build 导致 /var/lib/docker/buildkit 或 /var/lib/docker/builder 下缓存层爆炸式增长时；docker 构建缓存默认不自动清理，长期堆积会耗尽磁盘空间或 inode，引发“no space left on device”错误。
直接清理构建缓存是最有效的应对方式，尤其当频繁 docker build 导致 /var/lib/docker/buildkit 或 /var/lib/docker/builder 下缓存层爆炸式增长时。Docker 的构建缓存虽能提速，但默认不自动清理，旧缓存长期堆积会迅速吃光磁盘空间，甚至耗尽 inode——这正是“明明还有空间却报 no space left on device”的常见原因。
确认缓存是否真成主因
先别急着删，用两行命令快速验证：
-
docker builder prune -f：查看当前构建缓存占用（输出会显示释放量） -
du -sh /var/lib/docker/buildkit /var/lib/docker/builder 2>/dev/null：直查底层目录大小（部分版本用buildkit，老版本用builder）
如果单个目录超几 GB，或 docker system df -v 中 “Build cache” 一栏占比异常高，基本可锁定问题。
安全清理构建缓存
推荐从保守到彻底分步操作，避免误伤正在使用的构建上下文：
- 只清未被引用的缓存层：
docker builder prune（交互式，会提示确认） - 跳过确认、静默执行：
docker builder prune -f - 连带已构建但未被任何镜像引用的“孤立缓存”也清掉：
docker builder prune -a
注意：-a 不会影响正在运行的构建任务，但会删除所有未被当前镜像构建链引用的中间缓存，适合 CI 流水线构建后批量清理。
预防下次爆满：构建时主动控制缓存
治标更要治本。在 docker build 命令中加入参数，让缓存更可控：
- 禁用缓存（适合调试或确定要重来）：
docker build --no-cache ... - 限制缓存使用时长（例如只保留 24 小时内的）：
docker build --cache-from type=registry,ref=your-registry/cache:latest --cache-to type=local,dest=./cache,mode=max ... - CI 环境建议加
--progress=plain配合日志分析，便于发现哪一层缓存失效最频繁
配合检查 inode 是否告急
构建缓存由海量小文件组成，极易耗尽 inode。若清理后仍报错，立即执行：
-
df -i /var/lib/docker：看IUse%是否达 100% - 若接近满，需额外清理悬空镜像和停止容器：
docker system prune -f（它会顺带清掉大量小文件型资源）
不复杂但容易忽略
