企业官网建设流程全解析

1. 先说清问题的根源：Docker 在 macOS 上是怎么吃磁盘的

如果你也是个 macOS 上重度使用 Docker 的开发者，大概率经历过这样的场景：电脑磁盘明明还有 100G，用了几个月 Docker 之后，打开“关于本机”一看，可用空间只剩下 12G。跑到 Docker Desktop 里把不用的容器、镜像一股脑删干净，空间纹丝不动。此时你多半会怀疑人生：东西都删了，磁盘去哪了？

先别急着格式化硬盘，这个问题其实不是玄学，而是 Docker Desktop 在 macOS 上特殊的存储机制造成的。理解这个问题之前，先要搞清楚 Docker 在 macOS 上到底把数据放哪儿了。Docker Desktop 本质不是一个原生 macOS 程序，而是跑在一个轻量级虚拟机里的 Linux 环境。你在 macOS 上安装 Docker Desktop，它会在你的用户目录下创建一个巨大的虚拟磁盘镜像文件，所有镜像分层、容器可写层、数据卷，全都写在这个镜像文件里。

macOS 上的 Docker 磁盘占用异常，底层原因就两条：

第一，虚拟磁盘文件会“只涨不缩”。这个文件在创建时是稀疏文件（sparse file），也就是说逻辑上声明了 60G，实际只占用了已写入的部分。问题在于，你在容器里删除文件、删除镜像、删除卷，虚拟磁盘内部的块标记为“可用”，但这个可用空间并不会返还给 macOS 宿主机。文件系统层认为空间释放了，虚拟磁盘层却不知道要缩小，于是 Docker.raw 文件始终维持在历史最高水位。

第二，镜像分层的复用和孤儿层残留。Docker 的存储驱动（在 Docker Desktop 上通常是 overlayfs 的某种实现）会把每个镜像拆成多层，这些层在构建和拉取过程中会产生大量中间数据。构建缓存、临时容器、悬空镜像层，这些对象即使你看着“删了”，也可能因为引用关系没有真正释放。

所以标题里说的“提升磁盘使用率”，我理解为两层：一层是磁盘被 Docker 撑爆了，要降低实际占用；另一层是虚拟磁盘内部空间严重浪费，有效使用率很低。这两层问题都要解决，缺一个都不行。

这篇东西不是讲理论，是我自己在这台 mac 上反复折腾、删坏了不止一次、最终摸索出来的一套完整流程。我会把每一步操作、每一条命令背后的原因讲清楚，包含踩过的坑。如果你现在磁盘告急，照着从第 3 节开始操作就行；如果只是想搞明白原理，整篇都不算长。

2. 治本不治标：先做一次彻底的对象清理

很多人的第一反应是去 Docker Desktop 图形界面里点“删除”，或者手动docker rmi。这么做不是不行，但用处有限——你只是把“看得见”的对象删掉了，大量隐藏在构建缓存、悬空层、停止状态容器里的垃圾还躺在磁盘上，并且它们同样占用虚拟磁盘空间。所以第一步，先做一次系统级清理。

2.1 docker system prune 系列命令：该不该加 -a 和 --volumes

Docker 提供了一组 prune 命令，专门用来清理不在使用中的对象。最常用的是docker system prune，它默认清理三类东西：已停止的容器、未被任何容器引用的网络、悬空镜像（dangling images）。这三个清理完，通常能释放一部分空间，但不够彻底。

真正的重头戏是docker system prune -a，-a表示“all”，会把所有未被运行中容器使用的镜像全部删掉。“未被使用”指没有容器（包括停止状态的容器）引用它。很多镜像拉下来之后，你只是临时跑了几次，容器删了之后镜像就没用了，这些都会在这一步被清掉。我实测下来，这类镜像往往占据虚拟磁盘里最大的份额。

还有--volumes参数。这个参数很多人会犹豫，因为它会删除未被任何容器使用的数据卷。我提醒一句：如果卷里面存了数据库文件、配置、临时导出数据，一旦删除不可恢复。我的建议是第一次清理时不要加--volumes，先把容器、镜像、缓存清干净，看看释放了多少；如果空间还不够，再单独处理卷。

实际操作中，我习惯拆成两步，避免一条命令把所有东西都摧毁：

# 第一步：常规清理，保留所有卷 docker system prune -a -f # 第二步：单独清构建缓存（这个是空间大户） docker builder prune -f

-f是不加交互确认直接执行，如果你心里没底，可以先不加，看一遍它列出了哪些对象再确认。

2.2 镜像、容器、卷、构建缓存的专项清理

docker system prune能覆盖大部分对象，但有几个专项清理命令会更有针对性，适合处理不同场景：

我自己在实际操作中的顺序是：先container prune，再image prune -a，然后是builder prune，最后根据磁盘情况决定要不要volume prune。为什么这么排？因为容器是引用镜像的锚点，先把停止状态的容器清掉，后面的镜像清理才能判断出哪些才是真正没被引用的；镜像清完了，构建缓存里那些依附于镜像层的缓存才能彻底释放。

另外有个细节：不要频繁执行 builder prune。构建缓存的价值在于，当你重新构建同一个项目时，可以复用之前的缓存层，大幅缩短构建时间。如果你每构建一次就清一次缓存，等于把磁盘空间换成了构建速度。合理的节奏是一周清一次，或者确实发现磁盘紧张了再清。

2.3 清理后的验证方法与安全边界

清理完不要急着看 macOS 的磁盘空间，注意：此时虚拟磁盘内部的可用空间依然没有返还给宿主机。你先在容器环境内验证一下效果：

docker system df

这个命令会输出四列：TYPE（类型）、TOTAL（总数）、ACTIVE（活跃数）、SIZE（占用）、RECLAIMABLE（可回收量）。重点看最后两列，RECLAIMABLE 越大，说明虚拟磁盘内部垃圾越多，后续回收空间的效果越明显。

如果docker system df显示 RECLAIMABLE 为 0或者很小，说明当前仓库里确实没有什么可清理的了，空间占用都是“活着”的数据。此时磁盘依然被占满，那就说明问题出在虚磁盘自身无法收缩，继续往下看第 3 节。

安全边界我反复强调一遍：docker system prune -a --volumes -f这种组合拳，只能在你非常确定所有数据卷都不需要保留的情况下使用。我身边不止一个同事，清理完之后发现本地数据库项目的卷没了，辛苦积攒的测试数据直接蒸发。做任何涉及--volumes的清理之前，先docker volume ls看一眼，把需要保留的卷挂载到一个临时容器里复制出来。

3. 重头戏：回收虚拟磁盘里的“幽灵空间”

对象清理完成后，磁盘占用可能纹丝不动，这是最迷惑人的阶段。现在进入真正关键的部分——把虚拟磁盘内部的可用空间“吐”回给 macOS 宿主机。

3.1 磁盘瘦身的两种路线：重启后 Trim 与 Compact 功能

前面说过，删掉的镜像、容器、缓存只是在虚拟磁盘内部标记为可用，宿主机的 Docker.raw 文件并不会自动缩小。要让空间真正归还宿主机，需要触发一次磁盘整理（trim/compact），把文件系统层已释放的块同步给虚拟磁盘层。

两条路线：

一是重启 Docker Desktop 并利用虚拟机的自动 trim 能力。较新版本的 Docker Desktop 在关机时会尝试对虚拟磁盘做一次 trim，把内部可用块返还给宿主机。这个方法零成本，但缺点是效果不稳定，取决于具体版本和虚拟磁盘文件格式。有时候重启一下确实能看出空间变化，有时候完全没反应。

二是使用 Docker Desktop 内置的 Compact Disk 功能。这个功能在不同的 Docker Desktop 版本里位置不太一样。常见入口在 Dashboard 的 Troubleshoot 页面，点开后找 “Clean / Purge data” 区域，里面通常有类似 “Compact disk” 按钮；也有版本把它放在 Settings 的 Resources 面板里。它会停止虚拟机、对虚拟磁盘执行一次瘦身整理，然后把磁盘文件压缩回实际数据大小。

如果上述两个入口都找不到，换一个思路：直接删掉虚拟磁盘文件重建，这个后面细说。核心逻辑都是一样的，就是让虚拟磁盘文件重新匹配当前真实数据量。

3.2 实测流程：从清理到空间回收的完整走一遍

我在这台机器上实测有效的完整流程如下：

# 第 1 步：常规清理，保留卷 docker system prune -a -f docker builder prune -f # 第 2 步：检查可回收量 docker system df

做完上面两步之后，确认没有需要保留的数据卷了（这一步务必自己先确认），然后进入 Compact 阶段：

1. 打开 Docker Desktop，进入 Troubleshoot 页面；
2. 如果版本里有 “Compact disk” 按钮，直接点击；
3. 工具会提示“此操作将重启 Docker”，确认后等待；
4. 完成后回到 macOS 系统设置查看可用空间，你会看到可用容量明显增加。

如果你用的版本没有 “Compact disk” 按钮，可以手动触发一次 trim。Docker Desktop 的虚拟机是基于 LinuxKit 的，你可以通过 docker CLI 进入虚拟机内部执行 fstrim，不过这样做比较绕，还要开特权容器。我的建议是：优先找图形界面按钮，找不到就直接走重置路线。

3.3 彻底翻篇的方式：导出导入镜像、重置 Docker Desktop

如果上面的操作没能解决问题，最后一招是重建虚拟磁盘。两个层级，按严重程度递增：

层级一：保留镜像数据，导出再重来。把当前所有镜像用docker image save导出为 tar 包，然后在 Docker Desktop 里执行重置，之后再docker image load导回来。值得注意，docker save保存的是完整镜像分层结构，能最大程度保留原有镜像，缺点是 tar 包体积可能很大，而且导出前最好先确认这些镜像以后还需要用。

层级二：什么都不保留，直接重置 Docker Desktop。在 Troubleshoot 页面找 “Reset to factory defaults” 选项，或者在Settings -> Resources相关位置执行重置。这个操作会删除所有容器、镜像、卷和构建缓存，也就是把虚拟磁盘文件整个复位。重置后，Docker Desktop 会重新创建一块“全新”的虚拟磁盘，宿主机上那块动辄 60G、100G 的 Docker.raw 文件被彻底释放，磁盘使用率瞬间恢复正常。

重置方案简单粗暴，但代价明显：本地拉取的镜像全部消失，需要重新 pull；数据卷里的东西全部没了；用了 docker compose 搭建的本地环境需要重新编排启动。所以我一般建议把这个方案当作最后保底手段，同时提醒自己：Docker Desktop 里不该存任何不可丢失的数据，需要持久化的数据应该挂载到宿主机目录，而不是放在数据卷里。

4. 日常防膨胀清单与高频问题排查

经历了上面的完整流程，磁盘基本回到健康状态。但如果不改变使用习惯，几个月之后同样的场景会再次上演。这一节说说诊断方法和长期维护的经验。

4.1 诊断占用：docker system df 与宿主机目录定位

发现问题要先诊断，不要上来就盲删。诊断两个层面：

容器环境内部，用docker system df看各类对象占用和可回收量。特别关注Build Cache那一行，很多人的磁盘膨胀主要是构建缓存贡献的，尤其是频繁改动 Dockerfile、反复构建同一项目时，缓存层会越积越多。

宿主机层面，确认虚拟磁盘文件的位置和实际体积。Docker Desktop 的数据通常存放在：

~/Library/Containers/com.docker.docker/Data/vms/0/data/

不同版本路径略有差异，也可以直接打开 Docker Desktop 的 Settings，在 Resources 或 Troubleshoot 页面查看磁盘镜像的路径和当前大小。如果看到这个目录下的 Docker.raw 文件远大于docker system df里所有对象占用之和，那就说明虚拟磁盘内部有大量可回收空间，问题就是前面的“幽灵空间”，直接做 Compact 或重置。

4.2 我踩过的坑和避坑方案速查表

这些坑我基本都在实战中踩过，总结成一张速查表，方便你对照排查：

关于卷的清理，如果实在需要清理又怕误删，可以加过滤器只删指定标签的卷：

docker volume prune -f --filter "label=tmp"

这要求你在创建卷时主动打上label=tmp之类的标记，没有标记的卷不动。这个方法适合在测试环境用，生产或开发环境不要轻易执行任何 prune。

4.3 长期使用习惯：把“瘦身”变成常态化操作

磁盘管理属于“治未病”，定期做比等爆了再救要省心得多。我个人的习惯是每周五下午做一次十分钟的例行维护：

1. docker container prune -f清掉停止的容器；
2. docker image prune -f清掉悬空镜像；
3. 看一下docker system df，如果 Build Cache 超过 2G，就docker builder prune -f；
4. 每月挑个不忙的晚上，做一次docker system prune -a -f加 Compact。

除此之外，有几个习惯性做法能显著降低磁盘膨胀速度：

• 不要把所有项目都用 Docker Desktop 拉镜像，用完就删，容器不要长期滞留；
• 数据卷尽量映射到宿主机目录$HOME/data之类的地方，别让数据沉淀在虚拟磁盘内部；
• 大镜像（超过 1G 的）优先考虑用轻量替代方案，或者基于更小的基础镜像构建；
• 定期检查 Docker.raw 文件的大小，和docker system df对比，做到心中有数。

5. 进阶：自动化清理脚本思路

如果你觉得每周手动执行命令太麻烦，可以把上述操作写成一个简单的 bash 脚本，配合系统级定时任务（比如 macOS 的 launchd 或 cron 风格的计划任务）实现自动清理。脚本本身并不复杂，关键是要把安全边界写进去。

5.1 一个保守安全的周期清理脚本

#!/bin/bash # docker-disk-cleanup.sh # 用法：手动执行或加入定时任务 LOG_FILE="$HOME/docker-cleanup.log" echo "===== Docker disk cleanup started at $(date) =====" >> "$LOG_FILE" # 清理停止状态的容器 docker container prune -f >> "$LOG_FILE" 2>&1 # 清理悬空镜像（不清理被引用的镜像） docker image prune -f >> "$LOG_FILE" 2>&1 # 清理构建缓存（超过一定体积才值得执行，这里检查一下) BUILD_CACHE_SIZE=$(docker system df --format '{{.BuildCacheSize}}' 2>/dev/null | sed 's/G//' | sed 's/M//') if command -v bc &> /dev/null; then if (( $(echo "$BUILD_CACHE_SIZE > 2" | bc -l) )); then docker builder prune -f >> "$LOG_FILE" 2>&1 fi else docker builder prune -f >> "$LOG_FILE" 2>&1 fi echo "===== Docker disk cleanup finished at $(date) =====" >> "$LOG_FILE" 2>&1

脚本里我刻意没有加-a和--volumes，就一个原因：自动任务没人盯着，最容易出事故的就是“顺手把不该删的删了”。悬空镜像清理已经能解决大部分常见问题，深度清理还得靠人工确认后再做，这个原则在自动化和半自动化运维里特别重要。

如果你希望连虚拟磁盘的 compact 也一起自动化，那就不适合用 CLI 简单实现了，Docker Desktop 的 GUI 操作本质上调用的是内部工具，命令行直接调用的方式在不同版本间并不一致，稳定性欠佳。所以我的建议是：自动化只做对象清理，compact 和 reset 这类高风险操作留给人来做。

5.2 脚本之外的几个细节

第一个细节：日志很重要。脚本里我加了LOG_FILE，每次自动清理都写日志。有一次我发现磁盘依然在膨胀，查日志才发现某个项目正在用 docker compose 高频创建容器，prune 根本追不上它创建的速度。没有日志，这种问题你很难定位。

第二个细节：定时任务的调度频率要克制。我测试过，过于频繁的 prune（比如每小时一次）不仅影响 Docker 性能，还会让后续镜像拉取和构建因为缺少缓存而变慢。每 24 小时跑一次是个相对合理的频率，真正需要紧急释放空间时，人肉介入比自动脚本更靠谱。

第三个细节：监控要落到实处。macOS 自带的df -h ~可以看主目录所在卷的使用率，把它配合脚本输出到同一个日志文件里，你就有了一个最简的“磁盘水位监控”。如果再想精细一点，可以定时记录du -sh ~/Library/Containers/com.docker.docker/Data/vms/0/data/，看 Docker.raw 文件本身的变化趋势。这比每次等到磁盘满了才后知后觉要强得多。

我个人在实际操作中的体会是，Docker 磁盘膨胀在 macOS 上几乎是一件“跑不掉”的事，但只要抓住两个关键点——虚拟磁盘文件不会自动收缩和定期清理不可省略——这个问题完全可以控制在可接受范围内。清理动作本身不难，难的是把清理变成习惯、把数据安全边界刻在脑子里。希望这篇记录能帮你少踩几个坑。