关键是提前定义规则而非事后救火，需明确留什么、清什么、谁触发、如何验证；通过定时执行docker image prune分层清理、构建缓存限流、私有仓库生命周期管理及三步验证，实现磁盘水位稳定控制。

设清理策略的关键是“提前定义规则，而非事后救火”。重点不是删多少，而是明确留哪些、清哪些、谁来触发、怎么验证。

本地镜像：用 prune 命令分层控制

本地 Docker 引擎不带自动 GC，但可通过定时任务 + docker image prune 实现轻量级自治：

• 每小时清悬空镜像（最安全）：docker image prune -f，只删未被任何标签引用的中间层
• 每天清未被容器引用的镜像（含带标签的）：docker image prune -a -f
• 按需定向清理：比如保留最近 3 小时内推送的 myapp 镜像，其余清掉：docker image prune -a -f --filter "reference=myapp:*" --filter "until=72h"

构建缓存与日志：必须同步限流

这两类常占磁盘超 60%，却最容易被忽略：

Docker Compose Linter

检查 docker-compose.yml 文件的安全问题、最佳实践和端口冲突

下载

• 构建缓存上限锁死：执行 docker builder prune -f --keep-storage 1g，防止 build cache 无限膨胀
• 容器日志轮转配置：在 /etc/docker/daemon.json 中加这段：

  {"log-driver":"json-file","log-opts":{"max-size":"10m","max-file":"3"}}

  修改后运行 sudo systemctl restart docker

私有仓库端：启用生命周期管理

清理要从源头发生，不能全靠人工或本地脚本：

• Harbor：进项目 → 策略 → 新建保留策略，推荐组合使用：
  ✓ 保留最新 5 个标签
  ✓ 显式保护 stable 和 latest
  ✓ 删除 30 天未被拉取的镜像
• 原生 Registry：需在 config.yml 启用删除功能：delete: enabled: true，再配合脚本调用 API 按 digest 删除 tag，最后执行 garbage-collect
• 务必关闭 latest 标签部署：它会让策略无法识别“哪个才是可弃版本”，建议改用语义化版本（如 v1.2.3）并绑定 CI 流水线

清理后必须验证是否真释放空间

不验证 = 白干。三步快速检查：

• 看整体占用：docker system df，重点关注 RECLAIMABLE 列
• 查悬空镜像残留：docker images -f dangling=true，结果应为空
• 盯单个日志大小：ls -lh /var/lib/docker/containers/*/*-json.log，每个不应超 10MB