优先用docker save而非export，因其保留完整分层结构和元数据，支持精确还原；导出速度瓶颈在于i/o和数据量，优化核心是提前瘦身镜像（如换alpine基础镜像、多阶段构建）并避免低效gzip压缩，改用zstd或直接保存未压缩tar。
导出大体积 Docker 镜像本身不耗 CPU 或构建时间，但 慢在 I/O 和压缩过程。真正影响速度的不是“导出动作”，而是镜像层数多、单层体积大、元数据冗余或磁盘吞吐瓶颈。优化核心是减少要写入 tar 包的数据量 + 加快写入效率。
优先用 docker save 而非 docker export
两者本质不同：
- docker save 保存的是镜像完整分层结构（含 manifest、config、所有 layer），可被 docker load 精确还原，支持多镜像、跨平台、带历史层复用；
- docker export 只导出某个容器的 运行时文件系统快照（即合并后的一层），丢失所有元数据、历史层、标签信息，无法还原原始镜像。
对大镜像而言，export 表面快，实则不可靠——它绕过了镜像设计本意，且无法用于 Kubernetes 部署、CI/CD 验证或离线分发。务必坚持用 save。
提前瘦身镜像再导出
导出速度与最终 tar 包大小强相关。一个 3GB 的臃肿镜像，导出可能需数分钟；若先压到 80MB，导出常在 10 秒内完成。关键瘦身手段包括：
- 改用
alpine或distroless基础镜像（如node:18-alpine比node:18小约 80%） - 启用多阶段构建：编译用完整环境，运行只 COPY 二进制和必要依赖
- 在每条
RUN中清理缓存，例如：RUN apt-get update && apt-get install -y curl && rm -rf /var/lib/apt/lists/* - 用
.dockerignore排除.git、node_modules、logs/等无关目录
跳过 gzip 压缩（适用于局域网/高速磁盘场景）
docker save 默认不压缩，但很多人误加 | gzip 流式压缩，反而拖慢整体耗时——尤其在 SSD 或万兆内网环境下，磁盘写入速度远高于 CPU 压缩速度。
OpenClaw Docker Setup
下载
在 Linux 上通过 Docker 运行 OpenClaw，并使用 Tailscale 实现远程访问。⚠️ 涉及 sudo、Docker、Tailscale和凭证挂载——请先查阅安全章节...
推荐做法：
- 直接导出未压缩 tar：
docker save -o app.tar myapp:prod - 如需压缩，改用更快算法（非 gzip）：
docker save myapp:prod | zstd -T0 -o app.tar.zst（zstd 多线程压缩，比 gzip 快 3–5 倍） - 避免
docker save ... | gzip > app.tar.gz—— 单线程阻塞，易成瓶颈
批量导出时合并操作，减少重复层读取
若需导出多个版本（如 myapp:v1.0、myapp:v1.1、myapp:latest），它们很可能共享大量底层 layer。此时分别执行 docker save 会重复读取相同 layer 数据。
更高效的方式是：
- 一次命令打包多个镜像：
docker save -o multi.tar myapp:v1.0 myapp:v1.1 myapp:latest - Docker 自动去重，只写入一次共享层，tar 包体积更小，导出总时间更短
