刚接手运维就发现 Docker 有大量的 none 镜像，一下子慌了！

今天聊聊Docker里那些烦人的镜像：怎么来的，怎么删，怎么防

接手一个Docker环境，发现里面躺着一堆镜像，是不是有点无从下手？这事儿不少运维同行都遇到过。别急，今天咱们就把这事儿掰开揉碎了讲清楚：这些“无名氏”镜像到底是怎么冒出来的，怎么才能彻底清理干净，以及如何从源头上避免它们再次泛滥。

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

问题很常见，但处理起来有门道。下面就从根源说起。

1. none镜像是怎么产生的？

先说结论：这些镜像通常不是什么“异常产物”，而是“被新版本顶掉了标签的旧镜像”。说白了，就是镜像还在，但名字没了。

最常见的来源有四个：

（1）反复构建（Build）同一个标签

这是头号“元凶”。比如，你习惯用`latest`标签来构建镜像：

docker build -t app-api:latest .

第一次构建，一切正常。但当你第二次执行同样的命令时，新镜像生成，`latest`这个标签就自动从旧镜像身上“跳槽”，贴到了新镜像上。被抛弃的旧镜像，就变成了`:`。

（2）Docker Compose或CI/CD流水线自动构建

在`docker-compose.yml`里配置了`build`，并且镜像名用了`latest`标签：

build: .
image: app-api:latest

那么，每次执行`docker-compose up --build`，都会生成一个新镜像并覆盖`latest`标签，从而制造出一个新的镜像。文章开头那位同行遇到的情况，正是这个问题。

（3）构建过程失败或中断

构建过程中如果因为错误或手动中断而失败，Docker可能已经生成了部分镜像层，但没来得及成功打上最终的标签，这些中间产物也会以的形式残留。

（4）手动操作标签

这种情况相对较少，比如手动给镜像重打标签(`docker tag`)或删除某个标签，也可能导致原镜像失去标签，变成。

2. 删了，磁盘空间却不降？

这才是最让人困惑的地方：明明用`docker rmi`把那些镜像删掉了，为什么磁盘空间一点没见释放？

关键在于，你删除的镜像层并没有真正从磁盘上抹去，而是从“镜像层”的身份，转变成了“构建缓存（Build Cache）”。

为什么会这样？

现在Docker默认使用BuildKit来构建镜像，它非常“聪明”地考虑了构建效率。当你删除一个由`docker build`生成的镜像时，BuildKit会识别到这些镜像层可能对下一次构建有用，于是就把它们“收编”进了构建缓存里，以备不时之需。

看看下面的对比就一目了然了：

删除前，镜像占用空间：

删除后，镜像少了，但构建缓存增加了：

两图一对比就很清楚了：Images列表是清爽了，但Build Cache的体积却涨上去了。磁盘空间自然没有实质性释放。

3. 如何正确删除（释放空间四步法）

按照下面这个顺序来操作，既能清理干净，又不会影响正在运行的服务。当然，为求万无一失，操作前给环境做个快照总是个好习惯。

第一步：清理已停止的容器

docker container prune

这步是基础清理，移除那些已经停止运行的容器实例。

第二步：清理镜像

docker image prune

这个命令会交互式地询问你是否删除所有未被使用的悬空镜像（dangling images），也就是那些镜像。

第三步：清理构建缓存（关键步骤）

docker builder prune

这才是释放磁盘空间的“杀手锏”。它会清理无用的构建缓存。需要提醒的是，执行这步后，下次构建镜像时会因为缓存缺失而变慢一些，但为了换取宝贵的磁盘空间，这个代价通常是值得的。

第四步：验证空间释放情况

docker system df
df -h

分别用Docker自带的磁盘查看命令和系统命令检查一下，这时候你应该能看到磁盘使用率有了明显的下降。

4. 避坑操作：这些雷千万别踩

清理有方法，蛮干有风险。下面这两个操作，尤其要警惕。

（1）慎用“核弹”命令：docker system prune -a

docker system prune -a

这个命令威力巨大，它会删除所有未被容器使用的镜像，包括那些有正常标签的镜像。如果你有些镜像只是暂时没被运行，但后续还需要，这个命令就会导致镜像丢失。它还可能清理掉停止的容器（其中若有重要数据就麻烦了），虽然默认不删除数据卷，但整个操作风险较高，非必要不推荐。

（2）绝对不要手动删除Docker数据目录

有些人一着急，看到`/var/lib/docker/overlay2`目录占空间大，直接上手`rm -rf`。这无异于“自杀式”操作。这个目录是Docker存储镜像层和容器数据层的核心位置，直接删除文件系统内容，会导致Docker引擎彻底故障，所有容器和镜像都可能无法恢复。

所以，记住上面的“清理四步法”就足够了，千万别去动底层文件。

说到底，比学会删除更重要的，是理解Docker磁盘占用的这套机制。搞明白了镜像、容器、缓存之间的关系，以后再遇到这类问题，你就能从容应对，游刃有余了。