docker system df -v 显示的 volume size 是存储驱动估算值，不准确；真实占用需用 docker volume inspect 获取路径后，执行 du -sh 精确统计，尤其在 macos/windows 上必须跳过该值直接查宿主机路径。
docker system df -v 能直接看到 volume 占用，但数字不准
执行 docker system df -v 后，在 Volumes 区块里确实会列出每个 volume 的名称、驱动和标称大小，但这个 SIZE 值是 Docker 从存储驱动“报告”来的估算值，不是真实磁盘占用。尤其在 macOS 或 Windows 上，它常显示为 0B 或远低于实际 —— 因为虚拟磁盘层（Docker.raw 或 ext4.vhdx）不暴露底层文件系统统计。
- Linux 主机上相对准些，但仍可能滞后于
du结果，因 overlay2 层未及时 sync - macOS/Windows 必须跳过这一行，直接查宿主机挂载点路径
- 别信
RECLAIMABLE对 volume 的提示：volume 没有“可回收”概念，只有“被引用”或“未被引用”
怎么查 volume 真实磁盘占用（Linux/macOS/Windows WSL2）
核心逻辑只有一条：先拿到挂载点路径，再用系统命令测真实体积。Docker 不负责替你算这个。
- 用
docker volume inspect --format='{{.Mountpoint}}' <volume_name></volume_name>提取路径，比如返回/var/lib/docker/volumes/myapp_data/_data - Linux/macOS 直接运行：
sudo du -sh /var/lib/docker/volumes/myapp_data/_data - Windows WSL2 需先进入子系统：
wsl -d docker-desktop，再执行du -sh /var/lib/docker/volumes/myapp_data/_data - 批量查所有 volume 占用（Linux/macOS）：
docker volume ls -q | xargs -I {} sh -c 'echo {}; sudo du -sh /var/lib/docker/volumes/{}/_data 2>/dev/null' | sort -hr
为什么 Docker Desktop 图形界面显示的“大小”经常是空或 0B
Docker Desktop 的 UI 本质是调用 docker volume inspect API，而该接口在非 Linux 原生环境（即 macOS/Windows）中无法穿透虚拟机获取真实文件体积。它只返回元数据，不触发宿主机级 du 扫描。
- macOS 上，volume 数据实际存在
~/Library/Application Support/Docker Desktop/vms/0/data/Docker.raw内部，UI 无权读取该镜像文件的 ext4 分区结构 - Windows 上，路径虽映射到 WSL2，但 Docker Desktop 进程运行在 Windows 层，无法直接执行 Linux 系统命令
- 所以界面上的“大小”列基本只能当装饰看，真要判断是否该删，必须手动进终端跑
du
清理前必须确认的三件事
volume 一旦删了，里面的数据就没了，没有回收站。别只看名字觉得“没用”就 prune。
- 查谁在用：
docker ps -q | xargs -I {} docker inspect {} --format='{{.Name}} {{.Mounts}}' | grep <volume_name></volume_name> - 确认内容：
ls -lh /var/lib/docker/volumes/<volume_name>/_data</volume_name>，重点看有没有数据库文件（*.db）、日志（*.log）、上传附件（uploads/）等关键目录 - 检查创建时间：
docker volume inspect <volume_name> | grep Created</volume_name>，太新的卷大概率还在被开发流程依赖
最常被误删的是命名规范模糊的卷（如 6b8a3f1e7c9d 或 app_cache），它们往往承载着构建中间产物或测试数据库 —— 清理前务必进目录看一眼。
