“No space left on device”错误几乎从不表示系统根分区满了，而是Docker数据目录（Windows为WSL2的ext4.vhdx，macOS/Linux为/var/lib/docker）所在分区或虚拟磁盘已满；需用df -h $(readlink -f /var/lib/docker)或wsl -d docker-desktop-data df -h /精确定位，再结合docker system df分层清理，避免误删关键镜像与缓存。
直接说结论：no space left on device 错误几乎从不表示系统根分区满了，而是 Docker 自身数据目录（Windows 是 WSL2 的 ext4.vhdx，macOS/Linux 是 /var/lib/docker）所在分区或虚拟磁盘已满——哪怕你 df -h 看 C 盘还有 50GB，Docker 仍会卡死。
查清真实占用位置：别只看 df -h /
在 Windows 上，Docker Desktop 底层靠 WSL2 运行，所有镜像、容器、卷都存在一个固定大小的虚拟硬盘里，路径通常是：%LOCALAPPDATA%Dockerwsldataext4.vhdx。这个文件不会随删除操作自动收缩，可能显示“已用 118GB”，但实际内容只占 40GB。
macOS 和 Linux 则要确认 /var/lib/docker 挂载在哪——它可能单独挂在一个小分区（如 /var），而非跟 / 同一设备。
实操建议：
- Windows：运行
wsl -d docker-desktop-data df -h /，看输出中/var/lib/docker所在文件系统的使用率 - macOS/Linux：执行
df -h $(readlink -f /var/lib/docker)，避免被符号链接误导 - 通用：用
docker system df查各类型对象（Images/Containers/Volumes/Build Cache）各自占多少，定位大头
清理前先看清楚：哪些能删，哪些不能硬删
docker system prune -a 一键清空很爽，但会连带删掉所有未被容器引用的镜像（包括你本地 build 的、没打 tag 的），以及所有构建缓存——如果后续还要反复 build，等于白清。
更稳妥的做法是分层清理：
- 只删停止的容器：
docker container prune - 只删悬空镜像（
docker image prune - 只删无主卷：
docker volume prune - 删构建缓存（安全，不影响已有镜像）：
docker builder prune -a - 日志文件常被忽略：检查
/var/lib/docker/containers/**/*-json.log，单个可能几百 MB；可临时清空：truncate -s 0 *.log，或长期配置max-size限制
Windows 用户必做：压缩 WSL2 虚拟磁盘
即使你删光了所有镜像和容器，ext4.vhdx 文件大小也不会变小。这是 WSL2 的设计特性，不是 bug。
必须手动压缩，步骤缺一不可：
- 退出 Docker Desktop（右键托盘 → Quit）
- 管理员身份打开 PowerShell，执行：
wsl --shutdown - 启动
diskpart，依次输入：select vdisk file="C:Users\AppDataLocalDockerwsldataext4.vhdx"attach vdisk readonlycompact vdiskdetach vdisk - 重启 Docker Desktop
压缩后体积通常能减少 30%–60%，且不丢数据。
长期防复发：改存储路径或限制增长
频繁清理治标不治本。Windows 用户建议直接迁移 WSL2 数据目录到空间充裕的盘（如 D:Dockerwsl）：
- 导出：
wsl --export docker-desktop-data D:Dockerwsldata.tar - 注销：
wsl --unregister docker-desktop-data - 导入新位置：
wsl --import docker-desktop-data D:Dockerwsldata D:Dockerwsldata.tar --version 2
macOS/Linux 用户可修改 Docker daemon 配置，把 data-root 指向大容量分区，但需停服务、rsync 迁移、更新配置三步闭环，中途出错易导致 Docker 启动失败——这点容易被文档轻描淡写地跳过。
