镜像导出需配套交接文档，核心是明确导出目的、列出镜像名与标签、ID、基础镜像及架构、文件路径与SHA256校验值，并提供导入命令、验证步骤及风险提示，确保他人可正确复用。
镜像导出本身是技术动作，但交接文档决定它能否被他人正确复用。重点不是记录命令，而是让接手人清楚“为什么导、导了什么、怎么用、要注意啥”。
明确导出目的和适用场景
写清这次导出解决什么实际问题，避免后续误用。比如：
- “为测试环境部署 v2.3 版本 API 服务，导出构建完成的 api-server:2.3.0 镜像，不含构建缓存”
- “离线交付客户，需在无公网环境的 ARM64 服务器上运行，已确认镜像架构为 linux/arm64”
- “备份生产环境当前稳定镜像，用于紧急回滚，标签 prod-stable-20260715 对应 commit abc123”
列出镜像清单与关键元数据
不能只写“导出了 nginx”，要给出可验证的具体信息：
-
镜像名与标签：如
registry.example.com/app/web:1.8.2 -
镜像 ID（短格式）：执行
docker images --digests获取，例如sha256:9f86...c3a1 -
基础镜像与 OS 架构：如 “基于
debian:12-slim，目标平台linux/amd64” - 是否含多阶段构建产物：如 “仅含 final stage，build-stage 层已剥离”
注明文件路径、大小与完整性校验方式
交接包里不止一个 tar 文件，得让人知道怎么验、怎么传：
- 导出文件名与绝对路径：
/backup/images/app-web-1.8.2.tar - 文件大小（字节）：
124,876,543 B（便于传输后比对） - SHA256 校验值：
sha256sum /backup/images/app-web-1.8.2.tar输出结果 - 是否已压缩：
否（原生 tar，未 gzip；如需压缩请自行执行 gzip -k app-web-1.8.2.tar）
写清导入操作与验证步骤
告诉对方“拿到文件后该做什么”，而不是只甩一句“用 docker load”：
- 导入命令（带注释）：
docker load -i /tmp/app-web-1.8.2.tar # 会自动注册镜像，不启动容器 - 验证命令：
docker images | grep "app/web"和docker inspect app/web:1.8.2 | jq '.Architecture,.Os' - 关键检查项：标签是否匹配、架构是否一致、创建时间是否符合预期
- 常见风险提示：
若目标主机已有同名镜像，请先 docker rmi 或重命名，避免 tag 冲突
