docker save 导出的是含分层结构、manifest.json、repositories 和 config 文件的完整镜像快照，支持跨环境还原；而 docker export 仅输出容器文件系统扁平化 tar，丢失所有镜像元数据与分层信息。
直接用 docker save 导出镜像为 tar 包，是观察和验证镜像分层逻辑最可靠的方式。它不是简单打包，而是把镜像在存储驱动（如 overlay2）中的结构“快照”下来，保留完整的 layer 依赖链与元数据，因此能真实反映构建时的层级关系。
导出命令与基础验证
先确认目标镜像存在：
docker images | grep alpine
再执行标准导出：
docker save -o alpine-latest.tar alpine:latest
解压后检查内容：
mkdir alpine-struct && tar -xf alpine-latest.tar -C alpine-struct && ls alpine-struct
你会看到：manifest.json、repositories、一个或多个形如 abc123.../layer.tar 的目录，以及对应 abc123.../json 配置文件。
从 manifest.json 理清层序与入口
这个文件是整个镜像的“装配说明书”。打开它，典型结构如下：
[{ "Config": "8a25b1e0c74f/json", "RepoTags": ["alpine:latest"], "Layers": ["8a25b1e0c74f/layer.tar"] }]
关键点：
- Layers 数组顺序即叠加顺序：越靠前的 layer 是底层，越靠后的 layer 覆盖在其上；
- Config 字段指向最终运行时所用的配置文件（含 CMD、环境变量等），它不等于最顶层 layer 的 json，而是独立描述整个镜像行为；
- RepoTags 用于
docker load后自动恢复标签名，没有它，镜像仍可加载但无 tag。
逐层 inspect layer.tar 的差分本质
每个 xxx/layer.tar 不是完整 rootfs，而是相对于前一层的变更归档。可用以下方式验证：
mkdir layer0 && tar -xf 8a25b1e0c74f/layer.tar -C layer0
你会发现里面没有 /bin/sh 这类基础文件 —— 因为 alpine 最简，单层就包含全部。但对多层镜像（如基于 ubuntu 构建的 Java 应用），你会看到：
- 新增文件（如
/app.jar）直接出现在 tar 中； - 被修改的配置文件（如
/etc/apt/sources.list）只含新版本； - 被删除的文件以
.wh.<filename></filename>形式存在，表示“上层已移除”； - 权限变更（如 chmod +x）会体现在 tar header 中，而非文件内容变化。
这意味着：单独解压某一层，看到的是“叠加后效果”，但无法还原构建过程；只有按 manifest 指定顺序逐层叠加，才能复现原始镜像状态。
对比 docker export 理解元数据缺失风险
如果误用 docker export（需先运行容器）：
docker create --name tmp alpine:latest && docker export -o alpine-flat.tar tmp && docker rm tmp
解压后只会得到一个扁平化文件系统 tar，**没有 manifest、没有 repositories、没有 layer 分界、没有 config 文件**。它丢失所有构建上下文，也无法用于 docker load，仅适合做一次性文件提取。
所以：要分析层级逻辑，必须用 save；要用 tar 做迁移或备份，也必须用 save。
