关键在于构建 manifest list，即一份 JSON 索引文件，用于根据本地架构自动拉取对应平台镜像；可通过 buildx 从零构建或多平台镜像聚合实现，并需验证 manifests 数组及架构匹配。
靠一个镜像标签同时跑在 x86 和 ARM 设备上，关键不在“改运行时”，而在“建清单”——Docker 的 manifest list 就是这个机制的底层支撑。它不修改镜像内容，而是用一份元数据告诉 Docker：“当用户拉取 myapp:latest 时，请根据当前机器架构，自动选对应平台的镜像层。”
Manifest list 是什么，不是什么
它不是一个可运行的镜像，而是一份 JSON 格式的索引文件，类似“菜单目录”。里面明确列出：
- 该标签下包含哪些具体镜像（按 digest 引用）
- 每个镜像对应的平台：如
linux/amd64、linux/arm64 - 每份镜像的架构、OS、变体等完整标识
用户执行 docker pull myapp:latest 时，Docker CLI 会先拉取这份 manifest list，再根据本地 runtime.GOARCH 自动匹配并下载对应平台的镜像层。整个过程对使用者完全透明。
Docker Image Puller
下载
使用 Python 脚本下载 Docker 镜像并打包为 tar 文件。用户说“下载镜像”“拉取镜像”“pull xxx”“帮我下载 nginx 镜像”等时触发。支持 SOCKS5 代理直连（推荐）和国内镜像站加速两种模式。
构建双架构镜像的两种主流路径
实际落地分两类场景，选哪种取决于你有没有现成的单平台镜像：
-
从零构建（推荐）：用
docker buildx build一次性编译多平台镜像并推送到仓库docker buildx build --platform linux/amd64,linux/arm64 -t myreg.com/app:v1.0 --push .
Buildx 会调用 QEMU 模拟或远程构建节点，生成两份独立镜像，并自动创建 manifest list 推送至仓库。 -
聚合已有镜像：如果你已分别构建好
app:v1.0-amd64和app:v1.0-arm64，可用docker manifest手动组装：
先启用实验模式（修改~/.docker/config.json加"experimental": "enabled"）；
再执行：docker manifest create myreg.com/app:v1.0 myreg.com/app:v1.0-amd64 myreg.com/app:v1.0-arm64docker manifest push myreg.com/app:v1.0
验证与调试的关键检查点
光推上去还不够，得确认 manifest list 真正生效：
- 用
docker manifest inspect myreg.com/app:v1.0查看返回内容中是否有"manifests"数组，且含至少两个不同platform条目 - 在 ARM 设备上拉取后，运行
docker image inspect myreg.com/app:v1.0 | jq '.[0].Architecture'，应返回"arm64" - 在 x86 机器上做同样操作，应返回
"amd64" - 注意：某些私有仓库（如 Harbor 旧版）需开启 manifest list 支持；Docker Hub 默认支持
基础镜像选择直接影响兼容性
你的 Dockerfile FROM 行决定了最终能否顺利跨平台：
- 优先选带 manifest list 的官方镜像，如
alpine:latest、debian:bookworm-slim、python:3.11-slim—— 它们通常已预编译好多个平台版本 - 避免使用仅限单架构的基础镜像，例如某些定制版 Ubuntu 或老旧
ubuntu:18.04可能只提供amd64 - 若依赖特定二进制（如 PyTorch），直接拉取官方多平台 wheel（如
torch-2.3.0+cpu-cp311-cp311-manylinux2014_x86_64.whl）不如用官方镜像自带的预编译版本省心
