清理 docker 构建缓存是释放磁盘空间最直接有效的方式，尤其针对 /var/lib/docker/buildkit 或 /var/lib/docker/builder 目录膨胀问题；缓存不自动过期，易占满 inode 导致“no space left on device”；可通过 docker builder prune -f、du 和 docker system df -v 验证并分层安全清理；建议结合 --no-cache、ci 后自动 prune 及 buildkit 缓存导出等措施治本。
清理失效的 docker 构建缓存是释放磁盘空间最直接有效的方式，尤其当 /var/lib/docker/buildkit 或 /var/lib/docker/builder 目录因频繁构建膨胀到几 gb 甚至几十 gb 时。缓存不会自动过期，旧层长期堆积不仅占空间，还可能耗尽 inode，导致“no space left on device”这类看似有空间实则无法写入的报错。
先确认是不是构建缓存真在作怪
别急着删，两步快速验证：
- 运行
docker builder prune -f，看输出里“Total reclaimed space”有多少——如果显示几百 MB 到几 GB，基本就是它了 - 再执行
du -sh /var/lib/docker/buildkit /var/lib/docker/builder 2>/dev/null，直查底层目录大小（新版用 buildkit，老版用 builder） - 补查
docker system df -v，重点关注 “Build cache” 一栏的占比和绝对值，若远高于镜像或容器，就坐实了
分层次安全清理构建缓存
推荐按需选择，避免误删正在使用的中间层：
-
只清未被引用的缓存：运行
docker builder prune（交互式，会提示确认） -
静默清理未被引用的缓存：用
docker builder prune -f，适合脚本或 CI 流水线末尾调用 -
连带已构建但未被任何镜像链引用的“孤立缓存”也清掉：执行
docker builder prune -a，它不影响当前正在运行的构建任务，但会删除所有未被当前构建上下文复用的中间缓存层
顺手检查 inode 是否也被吃光
构建缓存由海量小文件组成，极易占满 inode。即使清理后仍报磁盘满，立即运行：
-
df -i /var/lib/docker：看 IUse% 是否接近或达到 100% - 若确实告急，补充执行
docker system prune -f，它会一并清理悬空镜像、停止容器、无用网络和大量小文件型资源
让下次构建不再失控
清理是救火，控制才是治本：
- 调试阶段加
--no-cache，强制跳过缓存，避免无效层叠加 - CI 构建后固定加
docker builder prune -f，形成闭环 - 启用 BuildKit 后，可配合
--cache-from和--cache-to把缓存导出到远程 registry，既共享又可控 - 在
docker build中加--progress=plain，便于日志中观察哪一层频繁失效，针对性优化 Dockerfile 指令顺序
