Docker Desktop 如何查看并限制容器磁盘占用

Docker Desktop 里要先分清两件事：查看谁占了空间，以及限制 Docker 引擎最多能使用多少空间。Images、Containers、Volumes 和 docker system df -v 用来定位占用；Settings > Resources > Advanced > Disk usage limit 设置的是 Docker 引擎总体磁盘上限，不是单个容器的独立配额。

Docker Desktop 官方地址：https://www.docker.com/products/docker-desktop/

官方设置文档：https://docs.docker.com/desktop/settings-and-maintenance/settings/

最稳妥的顺序是：先记录当前镜像、容器、卷和构建缓存的占用，再清理明确不需要的对象，最后根据剩余数据量设置总体上限。不要在没有备份的情况下直接把磁盘镜像上限调到低于现有数据量。

最终应该得到哪三个结果

完成后，你应该能回答三个问题：

1. 当前空间主要由镜像、容器可写层、卷还是构建缓存占用。
2. 某个容器的磁盘活动和文件变化是否持续增长。
3. Docker Desktop 所在后端是否支持 Disk usage limit，以及设置后的总上限是多少。

这三个结果不能用同一个数字替代。容器详情里的磁盘读写是活动指标，Images 和 Volumes 页面展示对象大小，docker system df -v 给出守护进程对象级汇总，而 Disk usage limit 控制的是 Docker Desktop 引擎可使用的总体空间。

步骤一：从 Images 和 Volumes 找到主要占用

1. 打开 Docker Desktop Dashboard。
2. 在左侧选择 Images。
3. 查看列表上方的镜像总数和总磁盘空间，再按 Size 排序。
4. 用 In use、Unused 或 Dangling 状态区分仍被容器使用的镜像。
5. 切换到 Volumes，按 Size 排序，并用 In use 与 Unused 筛选。

可见成功状态：Images 页面顶部出现镜像总占用，列表能按 Size 排序；Volumes 页面能看到每个卷的 Size 与使用状态。此时先记录最大的几个对象，不要立即批量删除。

镜像大小不能简单相加为真实新增占用，因为多个镜像可能共享层。Volumes 则常常保存数据库、缓存或上传文件，删除卷会删除其中数据。Docker 官方说明，使用中的卷不能直接删除；清理前应先确认关联容器和备份策略。

步骤二：进入容器详情核对持续增长

1. 在左侧选择 Containers。
2. 使用搜索框找到目标容器或展开 Compose 项目。
3. 选中容器后打开 Stats，观察 CPU、内存、网络和磁盘空间相关指标。
4. 切换到 Files，查看最近新增或修改的目录；对数据库和上传目录，优先确认它们是否应放到命名卷。
5. 若容器使用了卷，再到 Volumes > 目标卷 > Stored data 查看文件夹和文件大小。

可见成功状态：目标容器详情页已显示 Stats，Files 能看到容器文件系统内容；如果数据位于命名卷，Volumes 的 Stored data 页面能对应到具体文件大小。

这里最容易混淆的是“磁盘读写”与“磁盘占用”。读写量大说明 I/O 活跃，不一定代表文件持续变大；占用增长则要结合 Files、卷大小和下一步的 docker system df -v 明细判断。

步骤三：用 docker system df -v 保存对象级明细

Docker Desktop 的界面适合快速定位，守护进程的完整分类则用官方 CLI 命令查看。打开你平时使用的命令行环境，先执行详细清单：

# 显示镜像、容器、卷和构建缓存的详细磁盘占用
docker system df -v

# 只看汇总，便于修改设置后做前后对比
docker system df

可见成功状态：输出包含 Images space usage、Containers space usage、Local Volumes space usage 和 Build cache usage 等区域。容器区域的 SIZE 反映容器可写层占用，卷数据单独列在 Local Volumes，不能把两者混成一个“容器大小”。

步骤四：先整理无用对象，再决定磁盘上限

不要把 Disk usage limit 当作自动清理规则。它只是总体容量边界，不能替你判断哪些镜像、卷或缓存可以删除。先在 Images 页面筛选 Unused 或 Dangling，确认没有容器依赖后再使用批量 Delete；Volumes 页面同样先筛选 Unused，但删除前必须确认数据可恢复。

如果空间主要来自容器可写层，应优先修改容器设计：把数据库、上传目录和需要保留的数据放到命名卷或 bind mount，并为应用日志配置轮转。单纯提高上限只会推迟磁盘再次被填满。

可见成功状态：重新执行 docker system df 后，RECLAIMABLE 或总 SIZE 与清理前相比发生了符合预期的变化；业务容器仍能启动，必要卷仍显示 In use。

步骤五：在 Resources Advanced 设置总体磁盘上限

1. 点击 Docker Desktop Dashboard 右上角的 Settings 图标。
2. 进入 Resources > Advanced。
3. 找到 Disk usage limit，查看当前上限与磁盘镜像使用情况。
4. 把上限调整到高于当前有效数据量、并为构建和拉取镜像保留余量的值。
5. 点击 Apply 或界面显示的应用/重启按钮，等待 Docker Desktop 恢复运行。

可见成功状态：Resources > Advanced 页面显示新的 Disk usage limit，Docker Desktop 状态恢复为 Running，容器和镜像列表仍可正常加载。

官方当前把 Disk usage limit 列为 Mac、Linux 和 Windows Hyper-V 后端的资源设置。Windows 使用 WSL 2 时，CPU、内存和 swap 主要由 WSL 2 utility VM 配置，界面项可能不同；不要照搬其他后端的路径。若页面没有该设置，先确认当前后端，而不是反复重装。

重要提醒：降低磁盘镜像最大尺寸可能涉及重建或删除现有磁盘镜像。Docker 的 Mac FAQ 明确提醒，缩小最大尺寸会删除当前磁盘镜像并导致容器与镜像丢失。任何平台在向下调整前，都应导出重要镜像、备份卷数据，并确保 Compose 文件或启动参数可重建容器。

步骤六：复核设置是否真正解决问题

1. 回到 Images，确认总镜像空间与主要大镜像仍在预期范围。
2. 回到 Volumes，确认业务卷仍在、状态正确。
3. 重新执行 docker system df -v，保存修改后的明细。
4. 运行日常构建与容器启动，观察是否出现空间不足或拉取失败。
5. 若占用很快重新增长，继续定位写入容器层的日志、缓存和临时文件，而不是再次盲目提高上限。

可见成功状态：设置页保留新上限，Docker Desktop 正常运行，关键容器可以启动，前后两次磁盘明细能够解释空间变化。

设置不生效时怎么处理

Resources 里没有 Disk usage limit

先确认操作系统和虚拟化后端。官方设置表说明该项与平台和后端有关，Windows WSL 2 与 Hyper-V 的资源控制方式不同。更新 Docker Desktop 后仍没有时，应按当前后端查官方设置说明。

上限调小后可用空间没有立刻增加

最大值、磁盘镜像文件显示值和宿主机实际占用不是同一个概念。稀疏磁盘文件可能显示较大的逻辑最大值，但实际占用更小。先用 Docker Desktop 的 Advanced 页面和 docker system df 交叉确认。

某个容器还是不断变大

Disk usage limit 只限制引擎总体空间，不会单独约束这个容器。检查容器 Files、日志路径、缓存目录和挂载；把持久数据迁移到受管理的卷，并配置应用自身的清理或日志轮转。

Images 很大，但删除一个镜像释放不明显

镜像可能共享层。docker system df -v 会区分 SHARED SIZE 与 UNIQUE SIZE；真正可释放的空间更接近未被其他镜像复用的独占层。

能不能直接移动 Docker 的磁盘镜像文件？

不要在文件管理器里直接拖动。官方建议通过 Settings > Resources > Advanced > Disk image location 选择新位置并应用，否则 Docker Desktop 可能失去对磁盘镜像的跟踪。

收尾记录

把修改前后的 docker system df -v 摘要、Disk usage limit、新的 Disk image location，以及已备份的卷名称记录到项目运维文档。以后再次出现空间告警时，可以直接比较是镜像增加、构建缓存积累、容器可写层膨胀，还是业务卷自然增长，而不是从头猜测。