磁盘红了，先别急着下单买新盘。如果你家里那台 NAS、迷你主机或者跑 WSL2 的笔记本上也塞了十几个容器，可以先花两分钟看看这个：Docker 用久了是真的会"吃"磁盘的，而且吃的方式很隐蔽——有人删完容器发现空间纹丝不动，有人一觉醒来系统盘直接爆满。
这不是我吓唬人，翻了一下最近半年各平台的真实翻车记录，三个数字挺扎眼：
一位极空间 NAS 用户给机器做清理，最后清出来 130G 的 Docker 垃圾，元凶是常年堆积的悬空镜像和废弃容器；
一台生产服务器磁盘冲到 100%，排查下来，光一个容器的日志文件就占了接近 200GB；
还有一台测试服务器磁盘告急，`docker system df` 一看，镜像和容器占用都不算高，真正的大头是 38G 的构建缓存（Build Cache）。
这三笔账，对应的是三个完全不同的"吃盘大户"。搞不清楚谁在吃，清理的时候要么白忙一场，要么一刀下去把自己的数据卷删了。
先做一件事：确认是不是 Docker 吃的
磁盘红了的原因很多，系统日志、下载目录、影视库都可能是元凶。先跑 `df -h` 看是哪个分区满了，再跑一句 `docker system df`，它会直接告诉你镜像、容器、数据卷、构建缓存各占了多少空间，以及每类里有多少是"可回收"（Reclaimable）的。加个 `-v` 还能看到每个镜像、每个卷的明细。
这一步别跳过。有人折腾半天 Docker 清理，最后发现是 journal 日志或者视频文件占的大头，纯属白费功夫。
Docker 的空间账单，一共四笔
第一笔是镜像本身，但这里有个最容易被误解的点：删容器不等于删镜像，删镜像也不一定释放空间。镜像是分层存储的（overlay2），很多镜像共享底层基础层，你拉了十个不同名字的镜像，底下可能有一半的层是重复的；反过来，旧的 tag 被新 tag 顶掉之后会变成 `
第二笔是构建缓存。只要你在本机 `docker build` 过，BuildKit 就会把中间产物缓存下来加速下次构建，这个缓存默认没有上限。频繁折腾自建镜像的人，几十 G 是常态，前面那个 38G 的案例就是。微信公众号
第三笔最坑：容器日志。Docker 默认的 json-file 日志驱动是不做轮转、不限大小的，容器一直跑，日志就一直写。跑 Jellyfin、qBittorrent、下载器、AI 服务这类长期在线的容器，几个月写出几十上百 GB 完全可能，200GB 就是这么来的。微信公众号
第四笔是"删了也没还给你"的幻觉盘。在 Windows（WSL2）和 macOS（Docker Desktop）上，Docker 的数据是装在一个虚拟磁盘文件里的（比如 WSL2 的 ext4.vhdx）。这个文件只会自动变大、不会自动变小——你在容器里删了 50G，vhdx 依然占着原来的大小，C 盘看起来还是红的。知乎这笔账在 Linux 服务器上不存在，但在笔记本党这里是重灾区。
清理之前，先看风险等级
确认了空间在哪，才是动手的时候。这里把常用命令按风险分成三档，对着你的情况选：
风险等级 | 命令 | 它会删什么 | 适合谁 |
|---|---|---|---|
绿档，放心跑 | `docker image prune` | 只删悬空镜像（` | 所有人，日常保养 |
绿档，放心跑 | `docker container prune` | 只删已停止的容器 | 确定没有"临时停一下还要用"的容器 |
绿档，放心跑 | `docker builder prune --filter until=168h` | 只删 7 天前的构建缓存 | 经常 build 的人，那个 38G 就是这么清的 |
黄档，看一眼再跑 | `docker system prune` | 停止的容器 + 没在用的网络 + 悬空镜像 + 构建缓存 | 想一次清干净的，注意：不会动数据卷 |
红档，新手别碰 | `docker system prune -a --volumes` | 在黄档基础上，再删所有没被使用的镜像和数据卷 | 只有你清楚每个卷里装的是什么的时候 |
红档单独说两句：`–volumes` 删的是"当前没有容器在用"的数据卷，但"没在用"不等于"没价值"——你临时停了数据库容器，卷里的数据一旦被清，就是真丢。所以带 `–volumes` 的命令，跑之前先用 `docker system df -v` 把卷列表过一遍，或者干脆手动指定只删你认识的那几个镜像，别图省事一把梭。
至于 Windows 用户那笔"幻觉账"，prune 完之后还要多做一步：关掉 WSL（`wsl --shutdown`）再压缩 vhdx 文件，空间才会真正还给 C 盘；较新的 WSL 版本也支持把磁盘文件设成稀疏模式，能缓解一部分只涨不缩的问题。
比起删，更值钱的是让它别再涨
清一次只能救急，真正省事的是三个一次性配置：
第一，给日志加轮转。编辑（或新建）`/etc/docker/daemon.json`，加上 `“log-opts”: {“max-size”: “100m”, “max-file”: “3”}`，重启 Docker 生效。从此每个容器最多留 300MB 日志，200GB 那种事故从根上杜绝。微信公众号
第二，给构建缓存定个清理节奏。比如每周跑一次 `docker builder prune --filter until=168h`，只保留最近一周的缓存，速度和空间两不耽误。
第三，想清楚 Docker 数据放在哪块盘。Linux 上可以用 `data-root` 把 Docker 数据目录迁到大容量盘；NAS 用户的容器数据一般在存储池的隐藏目录里，如果你的系统池只是块小 SSD，早点把容器数据挪到机械盘池，比买新盘便宜得多。
最后说要不要买盘
我的建议是先观察一周再决定：每天跑一次 `docker system df`，如果增长主要来自构建缓存和日志，做完上面的配置基本就不涨了，这钱能省；如果镜像本身确实在稳定增长（比如你在玩多个 AI 模型镜像，每个都是几十 G），那才是真正的容量需求，这时候买盘才买得明白。
后续值得留意的信号：`docker system df` 里 Reclaimable 一列长期超过 30%、某个容器日志单文件超过 1G、NAS 系统池占用悄悄爬过 80%。出现任意一个，就该回来做一轮清理了。
