Docker 又吃了我 40GB 硬盘：从诊断到清理的完整指南

摘要：Docker 的磁盘占用是"只增不减"的——镜像、容器、卷、构建缓存一层层堆叠，直到你的 Mac 弹出"磁盘空间不足"。本文提供一套系统化的 Docker 磁盘空间管理方案：先用 SpacePeek 快速定位 Docker 目录的大小和位置，再用 docker system df 分析各环节的精确占用，最后按安全等级分级清理（从悬空镜像到未使用卷到构建缓存）。每一步附命令和预期释放量。文末给出一个防复发的日常维护脚本。

本文信息：基于 macOS 15.0 Sequoia / Docker Desktop 最新版 / 2026 年 7 月实测。

---

一、问题背景

Docker 是所有 Mac 程序员的第一大隐形磁盘杀手

如果你是一个用 Docker 的程序员，你的 Mac 硬盘上大概率有一个 20-50GB 的隐形黑洞。它不是你的项目代码，不是你下载的安装包——它是 Docker 的镜像、容器、卷、构建缓存。

最糟的是，Docker 只增不减。你 docker pull 一个新镜像、docker build 一个 Dockerfile、docker run 一个测试容器——每一次操作都在堆叠数据。当你不 pull、不 build、不 run 的时候，这些数据仍然留在你的硬盘上。

这篇文章的目标：用两个诊断工具 + 几行命令，把你的 Docker 磁盘占用从"不知道该删什么"变成"知道自己删了什么、还剩什么"。

阅读收益

• 知道 Docker 数据到底存在你 Mac 的哪个角落
• 掌握 docker system df 的精读方法
• 分级清理指南——从最安全的到最彻底的
• 一个防复发的日常维护方案

---

二、诊断：先搞清楚 Docker 吃了多少

---

第 1 步：用 SpacePeek 找到 Docker 的"老巢"

Docker Desktop for Mac 的数据存储在以下路径：

~/Library/Containers/com.docker.docker/

这个路径有两个特征：第一，大部分 Mac 用户从来不知道 Library 文件夹的存在；第二，Docker 的虚拟机磁盘镜像文件（Docker.raw）只增不减——即使你删除了所有容器和镜像，这个文件也不会自动缩小。

操作：

1. Finder → ⇧⌘G → 输入 ~/Library/Containers/com.docker.docker/ → 回车
2. 选中这个文件夹 → 按空格（需要装 SpacePeek）

你会看到：总大小 20-60GB，饼图里 Data/vms 子文件夹通常占了 90% 以上。这就是 Docker 的虚拟机磁盘镜像。

如果你没有 SpacePeek，右键 → 显示简介也能看到大小，但没有可视化饼图和子目录占比。在清理 Docker 这块，SpacePeek 的作用是让你确认 Docker 确实是当前磁盘占用的主要元凶——而不是凭感觉猜测。

---

第 2 步：用 docker system df 精确定位

SpacePeek 告诉你"Docker 在吃你的硬盘"，docker system df 告诉你"Docker 的内部构成是怎样的"。

docker system df

输出示例：

TYPE            TOTAL     ACTIVE    SIZE      RECLAIMABLE
Images          18        3         12.4GB    9.8GB (79%)
Containers      8         2         1.2GB     856MB (71%)
Local Volumes   5         1         3.6GB     2.8GB (78%)
Build Cache     24        0         4.8GB     4.8GB (100%)

精读这个表：

行	含义	重点关注
Images	18 个镜像，3 个在使用，12.4GB 总额	RECLAIMABLE 79% → 可回收的旧镜像占了 9.8GB
Containers	8 个容器，2 个在运行	停止的容器可以清
Local Volumes	5 个卷，1 个在挂载	未挂载的卷是"僵尸数据"
Build Cache	24 条，全都不在使用	100% RECLAIMABLE → 构建缓存全可以删

最常被忽略的是 Build Cache——每次 docker build 都会生成中间层缓存。你的 Dockerfile 改过 10 次，就有 10 版的中间层缓存堆在那里。100% 可回收。

---

第 3 步：深挖——看哪些镜像最大

docker images --format "table {{.Repository}}\t{{.Tag}}\t{{.Size}}" | sort -k3 -rh | head -10

输出示例：

REPOSITORY    TAG       SIZE
python        3.11      1.02GB
node          20        1.09GB
postgres      15        412MB
<none>        <none>    380MB    ← 悬空镜像，可以删
<none>        <none>    260MB    ← 悬空镜像，可以删

<none>:<none> 的镜像叫"悬空镜像"（dangling images）——你 pull 了一个新版本的镜像，旧版本的 tag 被移除，但它还在你的硬盘上。

---

三、清理：按安全等级分级操作

---

🟢 Level 1：最安全（推荐每月执行一次）

只删除明确不再使用且可重建的资源。零风险。

# 删除悬空镜像（<none>:<none>）
docker image prune

# 删除所有停止的容器
docker container prune

# 删除构建缓存
docker builder prune

# 删除未使用的网络
docker network prune

预期释放：3-8 GB

为什么这些是安全的：悬空镜像已经没有任何 tag 引用；停止的容器没有进程在跑；构建缓存在下次 build 时自动重建；网络配置不占什么空间，但清一下没坏处。

---

🟡 Level 2：中度清理（推荐每季度执行一次）

删除所有未被容器使用的镜像。镜像可以在需要时重新 pull。

# 删除所有未被任何容器使用的镜像
docker image prune -a

预期释放：5-15 GB

风险：如果你以后要基于某个镜像启动容器，需要重新 docker pull——有网络就能恢复。但如果你在飞机上或者没有 Wi-Fi 的环境，pull 一个 1GB 的镜像可能很慢。所以在执行之前，确保你知道哪些镜像你可能在近期会用到。

先在执行前看一眼会被删什么：

docker image prune -a --dry-run    # 列出会被删除的镜像，不会真删

---

🔴 Level 3：深度清理（磁盘红警时使用）

删除所有未使用的镜像、容器、卷、构建缓存。

docker system prune -a --volumes

预期释放：15-30 GB

⚠️ 注意 --volumes：这个参数会删除所有未被任何容器挂载的卷。如果你有用 docker volume create 手动创建的卷，且当前没有容器挂载它——它会被删。如果你不确定有没有重要的卷数据，先用以下命令看一眼：

docker volume ls                # 列出所有卷
docker volume ls -f dangling=true  # 只看未被挂载的卷

如果 dangling=true 列出的卷你都不认识——安全删。如果有你认识的卷名，先用 docker volume inspect 卷名 确认它挂载了什么路径。

---

🛑 终极方案：重置 Docker（Docker.raw 已膨胀到 50GB+）

症状：你已经清理了所有镜像、容器、卷，但 docker system df 显示的总占用仍然很高。这是因为 Docker Desktop for Mac 使用的虚拟机磁盘镜像文件（Docker.raw）不会因为你删除了内部数据而缩小。

验证：

ls -lh ~/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw

如果这个文件 30GB+，但你 docker system df 显示实际占用只有 5GB——说明 25GB 是 Docker.raw 的"空洞"（曾经被占用过的空间但文件没有压缩回去）。

唯一方式：重置 Docker：

Docker Desktop → Troubleshoot（故障排除）→ Reset to factory defaults（恢复出厂设置）。

⚠️ 这会删除所有容器、镜像、卷——相当于重装 Docker。执行之前：

1. 确保你的代码不依赖于任何 Docker 卷中的数据
2. 确保你知道如何重新 pull 你需要的镜像
3. 确保你没有正在运行的、不可中断的容器

---

四、清理后的诊断：确认效果

# 清理前后各跑一次，对比
docker system df

清理前：
Images   18  3   12.4GB  9.8GB (79%)
清理后：
Images   5   3   3.2GB   0B (0%)

回收了 9.2GB 镜像空间。

同时，回到 Finder，选中 ~/Library/Containers/com.docker.docker/ → 按空格。对比清理前后的 SpacePeek 饼图——如果 Docker.raw 文件本身已经膨胀，饼图中 Data/vms 占比不会显著下降（这就是 Level 3 解决不了的，需要终极方案的"重置"）。

---

五、预防：别再让 Docker 偷偷膨胀

日常维护脚本（建议设为每月执行一次的定时任务）

#!/bin/bash
# docker-monthly-cleanup.sh

echo "===== Docker 磁盘使用情况 ====="
docker system df

echo ""
echo "===== 开始清理 ====="

# Level 1：安全清理
echo "→ 清理悬空镜像..."
docker image prune -f

echo "→ 清理停止容器..."
docker container prune -f

echo "→ 清理构建缓存..."
docker builder prune -f

echo "→ 清理未使用网络..."
docker network prune -f

echo ""
echo "===== 清理后 ====="
docker system df

两个好习惯

习惯	命令
每次装新镜像后看一眼磁盘	docker system df
docker build 时加 --no-cache 避免不必要的缓存	docker build --no-cache -t myapp .（只在需要时用）
拉镜像时指定平台，避免拉多余的 multi-arch 镜像	docker pull --platform linux/arm64 node:20

---

六、总结

三点核心

1. Docker 的磁盘膨胀是"悄无声息"的。你不会收到通知、不会看到弹窗。直到有一天你的 Mac 弹出"磁盘空间不足"——彼时 Docker 可能已经吃了 30-50GB。用 docker system df 和 SpacePeek 的 Finder 文件夹扫描组合，每个月检查一次。

2. 清理有安全梯度。Level 1（悬空镜像 + 停止容器 + 构建缓存）毫无风险，建议每月执行。Level 2（未使用的镜像）需要确认你近期可能用到的镜像，但可以重新 pull。Level 3（--volumes）需要确认卷数据。终极方案（重置 Docker）是最后手段。

3. Docker.raw 不会自动缩小是这个品类最大的设计缺陷。你删了所有镜像和容器，Docker.raw 还是 30GB。这不是你的问题，是 Docker Desktop 的问题。定期检查这个文件的大小，必要时刻直接重置。

涉及的工具与命令

工具	作用	获取
SpacePeek	Finder 中查看 Docker 文件夹大小和分布	App Store 免费
docker system df	Docker 内部各环节占用分析	Docker 自带
docker system prune -a --volumes	彻底清理	Docker 自带

测试环境：macOS 15.0 Sequoia / Docker Desktop 26.x / 2026 年 7 月

---

你的 Docker 占用了多少硬盘空间？评论区晒一下 docker system df 的结果——我来看看谁的 Build Cache 最离谱。