关键是要提前配置自动清理规则而非等磁盘告警。通过 docker image prune 分层清理、构建缓存与日志限流、私有仓库生命周期管理及定期验证，可稳定控制磁盘水位。
关键不是等磁盘告警才删，而是提前配置“留什么、清什么”的自动规则。Docker 本身不带后台 GC 服务，但通过分层策略+定时清理+日志控制，能稳定守住磁盘水位。
本地镜像按需自动回收
用 docker image prune 系列命令构建轻量级自动清理：
- 只清悬空镜像（最安全）：
docker image prune -f，适合每小时 cron 执行 - 清所有未被容器引用的镜像（含带标签的）：
docker image prune -a -f，建议每天凌晨运行 - 加
--filter定向清理，例如：docker image prune -a -f --filter "reference=myapp:*" --filter "until=72h"，保留最近 3 小时内推送的 myapp 镜像
构建缓存与日志必须同步限流
这两类常占空间超 60%，却容易被忽略：
- 构建缓存：执行
docker builder prune -f --keep-storage 1g，把缓存上限锁死在 1GB - 容器日志：在
/etc/docker/daemon.json中配置轮转，例如：{"log-driver":"json-file","log-opts":{"max-size":"10m","max-file":"3"}}
修改后重启 Docker：sudo systemctl restart docker
私有仓库端启用自动生命周期管理
以 Harbor 或自建 Registry 为例，让清理从源头发生：
- Harbor：项目 → 策略 → 新建保留策略，勾选“保留最新 5 个标签”+“保留 stable/latest”+“删除 30 天未拉取的镜像”
- Registry：在
config.yml的storage段启用删除：delete: enabled: true，再配合脚本定期调用 API 按 digest 删除旧 manifest - 务必关闭
latest标签部署——它会让策略无法识别哪些是真正可弃版本
定期验证是否真释放了空间
清理后不验证 = 白干。执行三步检查：
- 看实际占用：
docker system df，重点关注 RECLAIMABLE 列 - 查悬空镜像残留：
docker images -f dangling=true，应为空 - 盯日志文件大小：
ls -sh /var/lib/docker/containers/*/*-json.log，单个不应超 10MB
