选对持久化方式关键在于明确保存目标：save针对镜像，保留分层结构、元数据和构建历史，适用于合规审计与CI/CD归档；export针对容器，仅导出扁平文件系统，适用于调试提取或临时状态备份。
选对持久化方式，关键不在命令怎么敲，而在于你真正想保存的是什么——是镜像的“构建身份”，还是容器的“运行快照”。
看对象：save 针对镜像，export 针对容器
docker save 操作的是镜像（image），它读取的是本地镜像仓库中已存在的、不可变的只读层集合；docker export 操作的是容器（container），哪怕这个容器已经停止，它导出的也只是该容器挂载点下 当前可写层与所有只读层合并后的文件系统视图。
- save 的输入必须是已存在的镜像名或 ID，比如
nginx:1.25或sha256:abc... - export 的输入必须是容器 ID 或名字，且该容器不必正在运行（stopped 状态也可导出）
- 试图对容器 run 后直接 export，得到的不是构建逻辑，而是那一刻的磁盘状态——比如日志、临时文件、甚至被手动修改过的配置
看内容：分层结构 vs 扁平文件系统
save 导出的 tar 包里包含多个 layer.tar 文件、每个层对应的 json 元数据、manifest.json（记录层顺序和 config 哈希）、以及 repositories（保存 tag 映射）。这些共同构成一个可复现、可验证的镜像定义。
export 导出的 tar 包里只有单一的根文件系统归档，没有 layer 结构，没有 manifest，也没有任何关于 CMD、ENTRYPOINT、ENV、WORKDIR 的记录——它就是一个 无上下文的 fs dump。
- save 后 load，镜像启动时自动执行原始 ENTRYPOINT/CMD
- export 后 import，新镜像默认没有启动命令，
docker run imported-img会报错 “no command specified” - 若用 import 创建镜像，必须显式指定启动命令：
docker import - myapp:v1 --change 'CMD ["/app/start.sh"]'
看合规性：审计追踪与环境一致性要求决定选型
在金融、政务或等保三级以上场景中，“可追溯”“可验证”“不可篡改”是硬性要求。此时 save 是唯一合规选择：
- 镜像 digest（sha256）在 save/load 全流程保持不变，可用于签名验签与完整性校验
- manifest.json 中的 history 字段完整保留每步 Dockerfile 指令，满足构建溯源需求
- export/import 会丢失所有构建历史，无法回答“这个镜像从哪来、怎么来的”这类审计问题
- CI/CD 流水线归档制品时，必须用 save —— 它对应的是经过测试验证的、带语义版本的镜像产物
看例外：export 的合理使用边界
export 不是错误命令，只是适用场景非常具体：
- 从调试容器中提取生成物（如编译好的二进制、打包后的 dist 目录）
- 备份某个临时容器的运行时状态（比如故障现场的 /var/log、/tmp 下的诊断文件）
- 跨平台轻量迁移：当目标环境无法运行完整镜像（如旧版 Docker 或受限沙箱），仅需还原文件内容时
- 注意：export 出来的 tar 不能作为镜像制品入库，也不能用于灰度发布、蓝绿部署等依赖镜像一致性的流程
