云服务器磁盘快满了，先别急着扩容：Docker 占用的排查与安全清理

小规格的云服务器上跑几个容器服务，是很多个人开发者的常见配置：盘本来就不大，系统、服务再加上 Docker，一段时间之后磁盘告警就来了。第一反应往往是扩容，其实很多时候盘不是被业务数据吃掉的，而是被 Docker 日积月累的“旧东西”占着：拉过又不用的镜像、停掉的容器、构建缓存，还有没人管的容器日志。

Docker 不会自动帮你回收这些东西，原因也合理：一个停掉的容器可能还留着要查的日志，一个旧镜像可能下次部署还要用。删不删，得人来判断。下面这套顺序，是先定位、再从稳到狠分级清理，最后复测确认。

第一步：先看 Docker 到底占了多少

系统层面先用 df -h 看整盘还剩多少，确认告警属实；然后不要急着全盘 du 慢慢扫，先看 Docker 自己的账本：docker system df。这一条命令会把镜像、容器、本地卷和构建缓存四类占用分别列出来，还会给一列 RECLAIMABLE，也就是理论上能回收多少。哪一类占得最多、哪一类可回收比例最高，一目了然。想细看每个镜像和卷的明细，再加 -v 参数。

这一步的意义是把“盘满了”变成“谁吃掉的”。四类里通常镜像和构建缓存是大头，卷则要格外小心，原因后面说。

第二步：分级清理，从最稳的一档开始

清理命令是一组 prune，区别在于删的范围不同，要按范围从小到大来，不要上来就抄网上那条“全清”命令。

第一档，docker container prune，只删已经停止的容器，运行中的不受影响。停掉的容器一般是升级后留下的旧版本，确认近期不需要回滚查日志，就可以清。

第二档，docker image prune，默认只删悬空镜像，也就是没有标签、没有被任何容器引用的层，这档基本无风险；再往上是加 -a，删所有未被容器使用的镜像，这时要先用 docker images 过一遍列表，确认没有留着备用的回滚镜像再执行。

第三档，构建缓存 docker builder prune。经常在本机构建镜像的机器上，缓存能攒到几十个 GB，清掉的代价只是下次构建慢一点，是性价比最高的一档。

把上面几档合起来的是 docker system prune，它默认清停掉的容器、未使用的网络、悬空镜像和构建缓存。注意一个关键点：它默认不删数据卷。这不是功能缺失，是保护。

第三步：数据卷是最危险的一档，别顺手清

网上流传的一键命令 docker system prune -a --volumes 里，最该警惕的就是 --volumes。数据卷里装的往往是数据库文件、上传文件、服务的持久化数据，镜像删了能重新拉，卷删了就是真没了。Docker 默认不动卷，正是因为它分不清哪个卷是垃圾、哪个卷是你的全部家当。

真要处理卷，先 docker volume ls 把列表看清楚，逐个确认不再被任何服务使用，并且里面的数据已经备份或者确实不要了，再单独执行 docker volume prune。拿不准的卷，宁可留着占一点空间，也不要赌。

第四步：别忘了容器日志

还有一类占用不在上面的账本里高亮，却经常是真正的元凶：容器日志。默认的 json-file 日志驱动不做轮转，一个话痨服务跑上几个月，单个日志文件长到几个 GB 很常见。排查时可以看 /var/lib/docker/containers 目录下各容器的日志文件大小。

处理上不要只做一次性截断，那是治标；更稳妥的是给日志加上限：在 Compose 文件里给服务加 logging 配置，设置 max-size 和 max-file，比如单文件 10m、保留 3 个，或者在 Docker 的 daemon.json 里做全局配置。改完之后老的大日志清掉，新日志就不会再无限长了。

第五步：清完必须复测

清理结束，命令会打印一行 Total reclaimed space，告诉你实际回收了多少。再跑一次 docker system df 和 df -h 对比前后数字，确认空间真的回来了、而且回来的正是你预期的那一类。最后用 docker ps 确认所有该在跑的服务都还正常运行，打开一两个服务页面看一眼能正常访问，这次清理才算收尾。

小结

Docker 磁盘清理的核心就两句话：第一，用 docker system df 先定位再动手，不要盲删；第二，prune 眼里的“未使用”和你眼里的“未使用”可能不是一回事，永远用刚好够解决问题的那条最窄的命令，卷和日志这两档尤其要单独确认。把这套排查做成定期检查，赶在告警之前处理，磁盘就很少会再给你“惊喜”。

（本文为个人运维实践记录，命令请在确认影响范围后再执行。）