今天聊聊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磁盘占用的这套机制。搞明白了镜像、容器、缓存之间的关系，以后再遇到这类问题，你就能从容应对，游刃有余了。
