docker镜像清理需兼顾空间、服务与安全，核心是分层识别、按需清理、自动兜底：先辨悬空镜像、闲置标签、过期测试镜像及漏洞镜像；再依环境执行四步法、registry api删除或企业级自动化规范。
清理 docker 镜像不是“删完就完事”，而是要兼顾空间释放、服务连续性与安全合规。核心在于分层识别、按需清理、自动兜底——不盲目删，也不长期堆。
识别哪些镜像真该删
先看清冗余来源，再动手：
-
悬空镜像（dangling images）：无任何标签、仅由构建中间层残留的镜像，ID 显示为
<none>:<none></none></none>，可安全清理 -
未被引用的已标签镜像：有标签（如
myapp:v1.2.3），但当前无容器运行、也未被其他镜像依赖，属“闲置但非僵尸” -
过期测试/临时标签：含
dev、test、feature/、日期后缀（如v1.0.0-20240501）且超 30 天未拉取的镜像 -
漏洞镜像：经扫描（如 Trivy、Clair）确认含高危 CVE 且无更新替代版本的旧基础镜像（如
python:3.7-slim）
本地环境清理四步法
适用于开发机、CI 构建节点等非生产环境：
OpenClaw Docker Setup
下载
在 Linux 上通过 Docker 运行 OpenClaw，并使用 Tailscale 实现远程访问。⚠️ 涉及 sudo、Docker、Tailscale和凭证挂载——请先查阅安全章节...
- 每日执行：
docker image prune -f清理所有悬空镜像 - 每周执行：
docker image prune -a -f --filter "until=168h"删除 7 天前未被使用的已标签镜像 - 清理构建缓存：
docker builder prune -f（尤其启用 BuildKit 后，缓存占比常超 50%） - 查漏补缺：
docker system df看RECLAIMABLE列，重点关注Build Cache和Images占比
私有仓库（Registry）安全删镜像
远程删镜像不能只靠 docker rmi，必须调用 Registry API：
- 先获取目标镜像 digest：
curl -I "https://reg.example.com/v2/myapp/manifests/v1.0" | grep Docker-Content-Digest - 再删除 manifest：
curl -X DELETE "https://reg.example.com/v2/myapp/manifests/sha256:abc123..." - 最后触发垃圾回收：
registry garbage-collect /etc/docker/registry/config.yml（否则磁盘不释放） - 建议封装为脚本，配合保留策略（如只留
latest+ 最近 3 个语义化版本）
企业级自动化运维规范
靠人工盯不现实，需嵌入流程：
-
CI/CD 流水线中加清理钩子：每次推送新镜像后，自动触发旧版本清理（如删除除
latest和v[0-9]+\.[0-9]+\.[0-9]+最新 3 个外的所有标签） -
统一元数据管理：用
docker inspect提取创建时间、标签、Labels字段，写入轻量数据库，支持 SQL 查询清理条件 -
磁盘水位告警联动：当
/var/lib/docker使用率 > 85%，自动触发docker system prune -f并通知运维 - 权限分级控制：普通开发者只能删自己命名空间下的镜像；安全团队有权批量下线含 CVE 的镜像
