不能直接跨架构迁移，必须确认CPU架构兼容性；Docker save导出的tar文件保留镜像层结构与元数据，但无架构转换能力，x86_64镜像在ARM主机上load后run会报“exec format error”；需通过docker inspect查Architecture、uname -m查宿主机架构，并用QEMU模拟或重新构建对应架构镜像。
不能直接跨架构迁移，必须确认 CPU 架构兼容性。
镜像本身不包含运行时架构适配能力
Docker save 导出的 tar 文件完整保留了镜像的层结构、元数据（如 CMD、ENV、LABEL）和构建信息，但不包含任何架构转换逻辑。x86_64 镜像在 ARM 主机上执行 docker load 后虽能成功注册到本地镜像列表，但后续 docker run 会因二进制指令不兼容而失败（报错类似 “exec format error”）。
- 镜像是否可运行，取决于其基础镜像和所含二进制程序的 CPU 架构（如 amd64、arm64、ppc64le）
- 可通过 docker inspect IMAGE_NAME | grep -i arch 查看镜像声明的架构字段（即 "Architecture" 和 "Os"）
- 多平台镜像（manifest list）需配合 docker buildx build --platform 指定目标架构构建，普通 save/load 无法生成或识别 manifest list
目标主机需具备运行该架构镜像的底层支持
若必须在异构机器上运行，有且仅有两种可行路径：
- 启用 QEMU 用户态模拟：在目标主机安装并注册 binfmt_misc（如通过 docker-binfmt 或 qemu-user-static），使内核能透明翻译 x86_64 指令到 ARM64；适用于调试或轻量场景，性能损耗明显
- 重新构建对应架构镜像：在目标架构机器或跨平台构建环境中（如 GitHub Actions + buildx），用相同 Dockerfile 重新 build 并 save；这是生产环境唯一推荐方式
避免常见误操作
导出导入过程本身不会报错，容易让人误以为迁移成功：
- docker load 成功 ≠ 镜像可运行 —— 必须紧接着测试 docker run --rm IMAGE_NAME true
- 不要混淆 docker export/import：它们操作容器快照，丢失分层和构建上下文，更无法解决架构问题
- registry 推拉同样受架构约束 —— docker pull 的镜像若无对应 platform 层，会 fallback 到不匹配的架构或报错
提前验证比事后补救更可靠
迁移前建议在目标环境做最小验证：
- 检查源镜像架构：docker inspect nginx:alpine | jq '.Architecture'
- 确认目标主机架构：uname -m（注意：aarch64 ≠ arm64，但通常可互认；x86_64 与 amd64 等价）
- 运行兼容性探测命令：docker run --rm --platform linux/amd64 hello-world（需 Docker 20.10+ 支持 --platform 强制指定）
