镜像体积不减小是因为下载解压数据已固化在中间层，rm仅标记删除；真正有效的是多阶段构建隔离大文件操作，或单阶段中用管道流式处理并合并清理到同一run指令。

直接在 dockerfile 中下载、解压再删除大文件，镜像体积不会变小——因为下载和解压产生的数据已固化在中间层，rm 只是加删除标记，不释放空间。用 tar 分离下载与解压本身不是目标，关键在于避免把临时大文件写入最终镜像层。以下是真正有效的做法：

用多阶段构建隔离下载解压过程

把下载、解压、编译等重操作放在构建阶段（builder stage），只把最终需要的二进制或资源 COPY 到精简的运行阶段（runtime stage）。

• 第一阶段用完整工具链镜像（如 python:3.12-slim 或 debian:bookworm-slim），完成依赖安装、源码编译、大包解压
• 第二阶段用极小基础镜像（如 alpine:3.19 或 gcr.io/distroless/python3），仅 COPY 运行时必需的文件
• 整个过程中，bigfile.tar.gz 和其解压内容从不进入最终镜像层

单阶段中用管道+tar流式处理，不落地存储

如果必须单阶段，就绕过磁盘写入：用 wget 或 curl 直接将压缩包通过管道交给 tar 解压，且不保留原始包。

Docker Encyclopedia

Docker 文档优先工作流：针对 Docker 特定问题、故障排除、命令规划、镜像/构建、容器/运行时操作及 Compose 等

下载

• 正确写法（无临时文件）：
  RUN curl -sL https://example.com/app.tar.gz | tar -xzf - -C /app --strip-components=1
• 错误写法（产生中间层冗余）：
  RUN wget https://example.com/app.tar.gz && tar -xzf app.tar.gz && rm app.tar.gz
• 注意：--strip-components 可精简目录结构，减少不必要的路径层级

解压后清理缓存和临时目录要合并到同一 RUN 指令

Docker 层不可变，每条 RUN 是一个新层。若解压和清理分两条 RUN，解压内容仍留在前一层。

• ✅ 合并操作：
  RUN curl -sL https://example.com/lib.tgz | tar -xzf - -C /tmp && cp -r /tmp/include /usr/local/ && rm -rf /tmp/*
• ❌ 分开写会失效：
  RUN curl -sL ... | tar -xzf - -C /tmp
RUN rm -rf /tmp/* → /tmp 内容仍在上一层

验证是否生效：用 docker history 看层大小

构建后立即执行：
docker history your-image:latest

• 关注 SIZE 列，确认含下载/解压操作的层没有异常大的数值（比如几百 MB）
• 若某层显示 135MB，但你只复制了一个 5MB 的二进制，说明该层混入了未清理的临时文件
• 配合 docker run -it --rm your-image:latest du -sh /* 2>/dev/null | sort -hr 快速定位大目录