推荐使用管道将docker save输出流直接交给gzip压缩，避免生成巨大中间tar文件，节省磁盘且提升效率；单镜像命令为docker save myapp:prod | gzip > myapp-prod.tar.gz，加载时用zcat myapp-prod.tar.gz | docker load。
导出 Docker 镜像时配合 gzip 实时压缩，核心是避免生成巨大的中间 tar 文件，直接用管道把 docker save 的输出流交给 gzip 处理。这样既省磁盘空间，又提升效率。
推荐做法：管道式实时压缩
这是最常用也最稳妥的方式，不落地临时文件，压缩过程与导出同步完成：
-
单镜像压缩：
docker save myapp:prod | gzip > myapp-prod.tar.gz -
多镜像打包再压缩：
docker save nginx:alpine redis:alpine | gzip > web-cache.tar.gz - 生成的
.tar.gz文件体积通常只有原始 tar 的 1/3–1/2，解压后仍可完整还原镜像层级和元数据
加载压缩包的正确方式
不能直接 docker load myapp-prod.tar.gz —— 它只认未压缩的 tar 流。必须先解压再加载，或用管道一步到位：
-
zcat myapp-prod.tar.gz | docker load（简洁高效，推荐） gunzip -c myapp-prod.tar.gz | docker load- 不建议先
gunzip myapp-prod.tar.gz解出 tar 再 load，白白多占磁盘
想进一步减小体积？试试 pigz 或 xz
如果传输带宽紧张、CPU 资源充足，可用更高效的压缩工具替代默认 gzip：
-
pigz（并行 gzip）：比 gzip 快数倍，压缩率相近
docker save myapp:prod | pigz --best > myapp-prod.tar.gz -
xz（高压缩比）：体积更小，但耗时明显增加，适合归档场景
docker save myapp:prod | xz -z -9 --threads=0 > myapp-prod.tar.xz
加载时用：xz -d -c myapp-prod.tar.xz | docker load
为什么不要先 save 再 gzip？
像这样分两步操作不推荐：
docker save -o app.tar myapp:prodgzip app.tar
因为第一行会立刻生成一个可能几百 MB 甚至上 GB 的原始 tar 文件，占用大量临时磁盘空间，尤其在 CI/CD 或资源受限环境容易失败。管道方式全程内存流式处理，无此风险。
