Docker镜像删除不释放空间，因分层机制仅标记删除而不擦除数据；多RUN指令加剧冗余；应合并操作、用多阶段构建、精简基础镜像并合理使用.dockerignore。
因为 docker 镜像的每一层都是只读且不可变的，删除操作只是在当前层添加一个“删除标记”，底层实际数据依然存在。
分层机制决定删除不等于释放
Docker 使用联合文件系统（如 Overlay2）叠加多个只读层。当你在某一层执行 rm 命令，系统不会擦除原始文件内容，而是在该层记录“这个路径下的文件已被移除”。运行时它会按顺序查找——上层的删除标记会屏蔽掉下层同名文件，但下层数据块仍完整保留在磁盘中。
例如：
- 第1层：写入 large.zip（100MB）
- 第2层：执行 RUN rm large.zip
最终镜像仍包含完整的 100MB 数据，只是第2层加了一条隐藏规则：“忽略 large.zip”。镜像体积不会变小。
多条 RUN 指令加剧冗余
如果下载、解压、清理分散在不同 RUN 中，大文件会在中间层“滞留”：
Docker Image Puller
下载
使用 Python 脚本下载 Docker 镜像并打包为 tar 文件。用户说“下载镜像”“拉取镜像”“pull xxx”“帮我下载 nginx 镜像”等时触发。支持 SOCKS5 代理直连（推荐）和国内镜像站加速两种模式。
- RUN wget app.tar.gz → 新增一层，存下 80MB 压缩包
- RUN tar -xzf app.tar.gz → 再新增一层，解出内容，但压缩包还在上层
- RUN rm app.tar.gz → 又一层，仅标记删除，不回收空间
三步产生三层，其中两层都含冗余数据。合并为单条 RUN 才能闭环处理。
真正减小镜像体积的方法
不是靠删，而是靠“不写进去”或“换一种写法”：
- 把下载、解压、清理写进同一行 RUN，让大文件生命周期完全封闭在单层内
- 用多阶段构建，只 COPY 最终产物（如二进制、dist 目录），彻底丢弃构建工具、源码、缓存等中间内容
- 基础镜像选 distroless 或 scratch，避免带 apt/apk 缓存、文档、日志等数百 MB 冗余
- 构建前用 .dockerignore 排除 node_modules、build、.git 等非必要目录，防止误 COPY
删除镜像后空间不释放？不只是镜像的事
即使你删掉了镜像，磁盘空间也可能没变化，原因有二：
- 层被共享：多个镜像共用同一基础层（如 ubuntu:22.04），删其中一个，共享层仍保留
- 构建缓存残留：docker build 过程产生的中间层、build cache 不显示在 docker images 里，却可能占几十 GB
可运行 docker system prune -a 清理所有未被引用的镜像、构建缓存、停止的容器和网络。
