真正省带宽的关键是先精简镜像本身（换轻量基础镜像、多阶段构建、合并清理），再结合导出时流式压缩（如gzip/pigz/zstd），双管齐下；加载时须管道解压后直喂docker load。
导出大镜像时，真正省带宽的关键不是“怎么压”，而是“压什么”——先让镜像本身变小，再用流式压缩传输，双线并进才有效。
导出时直接流式压缩，不落地大 tar 文件
docker save 输出的是未压缩的原始 tar 流，若先保存为 .tar 再 gzip，会多占磁盘、多一次 I/O。推荐一步到位：
-
通用首选 gzip：压缩率与速度平衡，兼容性最好
docker save myapp:prod | gzip > myapp-prod.tar.gz -
CPU 充足时用 pigz：多核并行，比 gzip 快 2–4 倍
docker save myapp:prod | pigz --best > myapp-prod.tar.gz -
带宽极度受限时选 zstd 或 xz：zstd -19 比 gzip -9 更小更快，Docker 23.0+ 原生支持 load；xz 压缩率最高但耗时长
docker save myapp:prod | zstd -T0 -19 > myapp-prod.tar.zst
加载时必须管道解压，不能先解再 load
压缩包不能直接 docker load，需解压后实时喂给 daemon：
- gzip / pigz 包：
zcat myapp-prod.tar.gz | docker load - zstd 包：
zstd -d -c myapp-prod.tar.zst | docker load - xz 包：
xz -d -c myapp-prod.tar.xz | docker load
源头精简镜像，才是压缩的根基
导出前镜像每小 100MB，压缩后就少传几十 MB。重点做三件事：
- 换轻量基础镜像：node:18-slim 比 node:18 小 50%+；alpine 镜像仅约 5MB；distroless 连 shell 都没有，更小更安全
- 启用多阶段构建：编译环境和运行环境分离，只 COPY 二进制或 dist 目录，彻底剔除源码、node_modules、.git、target/ 等
-
RUN 指令合并清理：apt/yum/apk 安装与缓存清理写在同一行，避免残留层
RUN apt-get update && apt-get install -y curl && rm -rf /var/lib/apt/lists/*
传输前再优化（按需）
如果已有大 tar 包且无法重构建，可进一步处理：
- 用
dive分析镜像层，定位冗余文件（如调试符号、文档、测试依赖），针对性优化 Dockerfile - 对已导出的 tar，可用
squashfs打包获得更高压缩比（需目标节点支持 squashfuse） - 若目标环境有 registry，优先走
docker push/pull——它自动按层传输、复用已有 digest，实际带宽远低于 save/load
