Docker 磁盘突然涨了，先别急着全局 prune。用 Buildx 构建器的话，可以先看缓存到底被哪些记录占着：
docker buildx du
想看得更细一点：
docker buildx du --verbose
环境：Docker Buildx 0.4+，命令只查看当前 builder 的缓存用量，不会删除内容。确认哪些缓存可以清理后，再按项目情况处理；多 builder 环境也要注意先切到实际构建用的那个。
多 builder 的机器上，先用 docker buildx ls 看当前 builder，必要时显式指定：
docker buildx du --builder mybuilder --verbose
不然只看到了默认 builder 的缓存，容易误判。确认记录后再决定是否清理，这个顺序挺稳。
再补一个边界：buildx du 只看构建器的缓存，不等于 Docker 整体数据目录的占用。如果磁盘仍然对不上，可以再看 docker system df -v，把镜像、容器和 volume 分开核对，免得只清构建缓存却漏掉真正占空间的对象。
HosuLv1#3 还有个容易忽略的点：如果 builder 用的是
docker-containerdriver，或者连的是远程 BuildKit，缓存实际在 builder 节点上。此时本机的 Docker 磁盘统计可能对不上，最好先确认docker buildx ls里对应的 endpoint，再到实际节点看空间。
确认哪些记录能清理后，可以再考虑按时间加过滤，避免一次性动掉所有缓存：
docker buildx prune --filter until=24h
它只作用于当前 builder 的构建缓存；真正执行前建议先确认 builder 和保留策略，CI 用的远程 BuildKit 也要在对应节点上处理。
如果 buildx du 直接提示 builder 不可用，可以先跑：
docker buildx inspect --bootstrap
它会检查并启动当前 builder，顺便把 driver、节点和 BuildKit 状态显示出来。远程 builder 的话，这一步也能先确认问题是在本地 CLI，还是实际构建节点。