· Jeff · 教程  · 4 分钟阅读

Docker悬空镜像与闲置镜像清理指南

搞清楚 docker image prune 和 docker rmi 的区别,精准清理 Docker 镜像,释放磁盘空间。

搞清楚 docker image prune 和 docker rmi 的区别,精准清理 Docker 镜像,释放磁盘空间。

Docker 悬空镜像与闲置镜像清理指南

用了 docker image prune 发现磁盘没腾出多少空间?不是命令不好使,是你清理的对象不对。


一、两种”没用”的镜像

Docker 有两类”没用但占磁盘”的镜像,很多人搞混:

1. 悬空镜像(Dangling Image)

docker images 中 REPOSITORY 和 TAG 都显示 <none>

REPOSITORY   TAG       IMAGE ID       SIZE
<none>       <none>    a1b2c3d4e5f6   1.2GB

通常是构建新镜像时旧版标签被摘掉留下的。没有任何容器引用,纯占磁盘。

2. 闲置镜像(Unused Image)

有正常的标签,比如 decolua/9router:0.5.40,但没有任何容器在用它。常见场景:升级到新版本后,旧版镜像的标签还在。

Dokploy 面板里会标 U(In Use),没标的就是闲置的。


二、怎么查

# 标准终端:看全部镜像
docker images

# 只看悬空镜像
docker images -f "dangling=true"

# 看哪些镜像正被容器使用
docker ps -a --format 'table {{.Image}}'

三、清理命令的区别(重点)

命令清理范围适用场景
docker image prune仅悬空镜像日常清理
docker image prune -f同上,跳过确认提示脚本/自动化
docker rmi <镜像:标签>精确删除指定标签删旧版闲置镜像

一句话总结

prune 只管 <none>:<none>,有标签的一律不动。

所以升级镜像后留下的旧版(比如 decolua/9router:0.5.40),prune 碰都不会碰。必须用 docker rmi 指名道姓删。

# 清理所有悬空
docker image prune -f

# 删除指定的旧版闲置镜像
docker rmi decolua/9router:0.5.40

四、实战演示

假设服务器上有 6 个镜像:

镜像标签大小在用处理
nousresearch/hermes-agentv2026.7.304GB保留
decolua/9router0.5.45849MB保留
mazzolino/resticlatest299MB保留
filebrowser/filebrowserv2.63.1455MB保留
decolua/9router0.5.40843MB
nousresearch/hermes-agentlatest5.3GB

清理后释放约 6.1GB 磁盘空间。

docker rmi decolua/9router:0.5.40 nousresearch/hermes-agent:latest

五、一键清理脚本

#!/bin/bash
# 清理悬空 + 指定旧版闲置镜像

# 1. 清悬空
docker image prune -f

# 2. 删已知旧版标签(按需修改)
docker rmi decolua/9router:0.5.40 nousresearch/hermes-agent:latest 2>/dev/null

# 3. 报告剩余
echo "=== 清理后 ==="
docker images --format 'table {{.Repository}}\t{{.Tag}}\t{{.Size}}'

六、注意事项

  • docker image prune 不会删除任何有标签的镜像,即使它们完全闲置
  • 删除前确认目标镜像不在任何容器(包括已停止的)中使用
  • 如果镜像被多个标签引用,docker rmi 只会摘掉指定标签,不删除实际层数据
  • 定期清理建议:悬空镜像每周一次,闲置旧版每次升级后立即清理,避免积压

☕ 如果这篇文章对你有帮助

欢迎请 Jeff 喝杯咖啡,支持我持续分享更多软件技巧~

打赏功能即将上线,先点个赞也是支持 ❤️

返回博客

相关文章

查看全部 »
1.3GB 内存的服务器上,浏览器自动化必然 OOM:我最后用纯 HTTP 重写了一遍签到

1.3GB 内存的服务器上,浏览器自动化必然 OOM:我最后用纯 HTTP 重写了一遍签到

一个每天跑的签到脚本,用 Playwright 时 6 分钟才启动完浏览器、随后必崩。我一度以为是脚本写得不对,换了三种写法都没用。真正的结论是:在 1.3GB 内存、swap 全满的机器上,浏览器自动化注定失败——不是代码问题,是物理问题。更值得记的是第二层翻车:当时得出的「必须借浏览器上下文」这个结论本身就是错的,而它被固化进了代码,白折腾了一周。

FileBrowser 免登录图片直链:容器部署 + Notion 嵌入完整指南

FileBrowser 免登录图片直链:容器部署 + Notion 嵌入完整指南

想让 Notion 页面直接嵌入服务器上的图片,又不想把 FileBrowser 的管理登录暴露给所有人?核心思路不是 FileBrowser 自带功能,而是 nginx 层用 alias 把图片目录直接映射出来绕过认证。这篇是完整实战指南,含部署、直链、验证和排障。