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 清理所有未被引用的镜像、构建缓存、停止的容器和网络。