多架构镜像需为各平台分别构建独立镜像，再通过oci manifest list逻辑聚合；docker依赖buildx+buildkit+qemu模拟实现跨架构构建与自动分发。
多架构镜像不是“一次编译适配所有平台”，而是为每个目标架构分别构建独立镜像，再用清单（manifest）把它们逻辑聚合。Docker 本身不跨架构编译代码，它靠 Buildx + BuildKit + QEMU 模拟环境来实现“在 x86 主机上产出 ARM64 镜像”这类操作。
Buildx 构建器实例隔离各架构构建过程
Buildx 的核心是构建器（builder），它不是简单命令，而是一个可配置、可启动的构建环境。默认 builder 只支持本地架构；启用多平台需创建专用 builder 实例，并挂载 QEMU 模拟器：
- 每个 builder 实例可绑定一种或多种驱动（如 docker-container 或 kubernetes），决定构建在哪种运行时中执行
- 调用
docker buildx create --use --name mybuilder后，该实例会初始化 BuildKit 引擎，并自动注册支持的平台（需提前安装 binfmt_misc） - 构建时，Buildx 会为
--platform linux/amd64和--platform linux/arm64分别调度独立构建任务，互不干扰
QEMU 提供运行时指令级模拟
真正让 x86 主机“跑通” ARM 编译流程的，是 QEMU 用户态静态二进制（qemu-user-static）。它不虚拟整台机器，只拦截并翻译用户空间的 CPU 指令：
- 当构建阶段执行
RUN apt-get install或COPY等操作时，底层进程实际运行在 QEMU 模拟的 ARM64 环境中 - 基础镜像（如
arm64v8/ubuntu:22.04）本身是 ARM64 架构，其二进制文件能被 QEMU 正确加载和执行 - 构建结果（如编译出的可执行文件、打包的依赖库）天然具备目标架构 ABI 兼容性，无需额外转换
Manifest 清单实现逻辑统一与运行时自动分发
Buildx 最终不会生成一个“万能镜像”，而是产出多个物理镜像（如 myapp@sha256:a1b2... 和 myapp@sha256:c3d4...），再用 OCI manifest list 把它们组织起来：
- manifest 是一个 JSON 文件，记录每个架构镜像的 digest、平台信息（os/arch/variant）、大小等元数据
- 推送时加
--push参数，Buildx 会先推各架构镜像，再推 manifest 到同一 tag（如myapp:latest） - 用户执行
docker pull myapp:latest时，Docker 守护进程读取 manifest，根据本机runtime.GOARCH自动选匹配项拉取，全程无感
基础镜像与 Dockerfile 指令必须支持目标平台
即使有 QEMU 和 Buildx，构建仍依赖生态配合。关键点在于：
- Dockerfile 中的
FROM必须引用已提供多架构变体的基础镜像（如alpine:latest、golang:1.23官方镜像都含 amd64/arm64 等） - 所有 RUN 指令中的工具链（gcc、node、python 等）需能在目标架构下运行——这由基础镜像保障，不是 Buildx 解决的
- 若使用私有 base 镜像，必须确保它已为各平台构建并推送到 registry，否则 Buildx 会在对应平台构建阶段失败
