健康维C1. 为什么突然要折腾多架构镜像
先说说我遇到的实际场景。公司内部的服务器长期以 x86_64 为主，但这两年 ARM 设备越来越多了：研发手里的 Apple Silicon MacBook、客户的边缘节点、云上的 ARM 实例，还有各种 ARM 开发板。以前的做法很简单，每个架构单独构建一份镜像，靠不同的 Tag 区分，比如 app-linux-amd64、app-linux-arm64。但维护起来真的累，Dockerfile 改一次，要在两台不同架构的机器上各构建一遍，推送两个 Tag，部署脚本里还要写一堆架构判断逻辑。
后来我换成了多架构镜像方案，也就是标题里说的这个事儿。所谓多架构镜像，本质上是让同一个镜像 Tag 背后同时包含多个平台的镜像，用户在任意架构的机器上执行 docker pull 时，Docker 会自动拉取对应架构的那一份。对使用者来说，体验和单架构镜像完全没有区别，docker run 一行命令直接跑，Docker Engine 帮你把背后的架构兼容问题全部处理掉了。
这个方案解决的核心痛点有两个：一是镜像维护成本高，二是集群里混合架构场景下部署逻辑复杂。如果你手上有树莓派、Rockchip 开发板、Apple Silicon 笔记本，或者云上的 ARM 服务器，同时又要和常规 x86 服务器共用一套镜像发布流程，那这篇文章就是为你准备的。下面我把我踩过的坑和最终跑通的完整方案一次聊清楚。
1.1 先理解镜像与架构的关系
很多人以为 Docker 镜像是平台无关的，其实这是个误解。镜像分两层看：最底层是文件系统层，这一层里装的二进制可执行文件、动态链接库、系统工具链，都是针对特定 CPU 架构编译的。x86_64 的 ELF 可执行文件放到 arm64 上直接跑，操作系统根本没法识别指令集，会直接报 exec format error。所以镜像天然就和 CPU 架构绑定。
Docker 本身只是“打包 + 运行”的载体，它不会替你做跨架构翻译。除非你在容器里跑的是纯解释型语言写的程序，比如纯 Python 脚本、Node.js 纯 JS 代码，那还有可能在不同架构上运行。但哪怕是这样，底层的 python:3.12 基础镜像本身也是分架构的。换句话说，跨架构运行的核心矛盾在基础镜像和编译产物层面。
1.2 多架构镜像到底长什么样
在 Docker Registry 里，一个多架构镜像 Tag 的元数据叫做 Manifest List，也叫 Image Index。以前单架构镜像的 Tag 直接指向一个 Manifest，Manifest 里记录各层的 digest；多架构镜像的 Tag 则指向一个 Index，Index 里面列出了一串 Manifest，每个 Manifest 对应一个 linux/amd64、linux/arm64、linux/arm/v7 之类的平台条目。
当客户端执行 docker pull 时，会先请求这个 Index，然后根据客户端自身的 os/arch 信息，只拉取匹配的那个 Manifest 对应的层。这个机制让“一个 Tag 多平台复用”成为可能。我在最初接触这个概念的时候，把它类比成快递分拣中心：同一个快递单号，背后可以对应不同运输路线的包裹，分拣中心根据收件人地址自动选路线。这里的“分拣中心”就是 Registry 的 Index 逻辑。
1.3 迁移场景下的硬刚需
如果你只是在一台 x86 服务器上自娱自乐，那确实不需要多架构。但下面这些场景就躲不掉了：云厂商的 ARM 实例因为性价比高被大规模采购，公司要求镜像必须能统一发布；客户现场有 ARM 网关，开发环境却是 Intel Mac，两边跑的容器镜像不能有差异；社区开源项目要给用户提供开箱即用的镜像，用户手里什么架构都有。任何一种情况出现，多架构镜像构建就不再是“锦上添花”，而是发布流程里绕不开的一个环节。
构建多架构镜像的方案业界基本统一了，核心就是 BuildKit 的 buildx 插件 + 跨架构模拟执行。下面我详细拆解整个方案，包括工具链原理和一步步实操。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 工具链选型：buildx、QEMU 与 binfmt
整套方案的骨架是 Docker 官方的 Buildx。Buildx 是 Docker BuildKit 的命令行前端插件，用来替代传统的 docker build。它最核心的能力之一就是通过 --platform 参数指定多个目标平台，一次构建同时产出多个架构的镜像，并直接推送到 Registry。
但这里有一个关键问题：在 x86 机器上，你怎么“构建”出一个 arm64 的镜像？构建过程不是简单的文件打包，它需要在目标架构环境下执行指令。比如 Dockerfile 里有 RUN apt-get install，这一步要在 arm64 环境里运行 apt 命令。x86 CPU 直接跑 arm64 的二进制是不行的，必须靠一层模拟层来翻译指令。
这层模拟就是 QEMU 的用户态模拟。QEMU 本身的强大之处在于它既做完整系统虚拟化，也做用户态程序模拟。我们这里用到的是后者：qemu-aarch64-static 和 qemu-arm-static 这类用户态模拟器。它拿到 arm64 的 ELF 可执行文件后，把每一条 ARM 指令翻译成 x86 指令去执行。翻译执行会产生性能损耗，但构建场景里是可接受的，下面我会专门讲如何缓解“慢”的问题。
2.1 binfmt_misc 的作用
有了 QEMU 模拟器，还差最后一步：让操作系统“知道”遇到 arm64 格式的可执行文件时，自动调用 QEMU 去处理。这就要用到 Linux 内核的 binfmt_misc 功能。它允许你注册一种自定义的二进制格式处理器，通过文件头魔数或扩展名来识别文件类型。Docker 官方社区提供的 tonistiigi/binfmt 镜像，其实就是帮你一次性注册好了 QEMU 用户态处理器到 binfmt_misc 中。
执行下面这条命令，就是整个方案里最容易被忽视但又极其关键的一步：
bash复制docker run --privileged --rm tonistiigi/binfmt --install all
--privileged 是因为注册 binfmt_misc 需要写 /proc/sys/fs/binfmt_misc/，这属于内核级操作，普通容器权限不够。执行完以后，你可以在宿主机上验证一下：
bash复制ls /proc/sys/fs/binfmt_misc/
正常情况下能看到 qemu-aarch64、qemu-arm、qemu-riscv64 等条目。后续每次开机之后，如果 Docker Desktop 的虚拟机重启了，或者你换了新的构建机，都需要重新执行一次注册，否则多架构构建会直接失败，而且报错很隐蔽，后面我会把排查思路整理出来。
2.2 为什么 builder 实例要选 docker-container
用 buildx 构建时，如果不做任何配置，默认使用 docker 驱动，也就是直接调用本机 Docker 守护进程。这个驱动有个限制：它只能基于本机内核直接执行构建，在跨架构构建时非常吃力，很多平台参数不支持。所以官方的推荐做法是创建一个 docker-container 驱动的 builder 实例。
这个驱动会在后台启动一个专用的 BuildKit 容器，由它来执行构建任务。构建任务的隔离性更好，也支持更多高级功能，比如多平台输出、缓存导出等。创建命令如下：
bash复制docker buildx create \
--name multiarch-builder \
--driver docker-container \
--platform linux/amd64,linux/arm64,linux/arm/v7 \
--use
拆开解释一下：
--name multiarch-builder：给这个 builder 实例起个名字，方便将来管理。--driver docker-container：使用独立的 BuildKit 容器驱动。--platform：声明这个 builder 支持哪些目标平台，这里我按实际需求写了 amd64、arm64、arm/v7 三档。--use：立即将当前终端默认 builder 切换过去。
创建完成后，可以用 docker buildx ls 查看状态，输出里应该能看到 multiarch-builder 行的 PLATFORMS 列包含了你声明的那些平台。这一步做完，构建环境就绪了。
2.3 Registry 准备与镜像加速配置
多架构镜像最终要推送到镜像仓库，一般就是 Docker Hub 或自建的 Harbor。Registry 本身天然支持 Manifest List，不需要额外配置。唯一要注意的是，如果你还在用很老的 Registry 版本，可能不支持 docker buildx --push 的多平台推送逻辑，建议至少升级到 Registry 2.8 以上，Harbor 则用 2.x 近期版本基本就够。
国内网络环境下，还有一个很实际的问题：构建过程要拉取大量基础镜像作为构建上下文。Golang 构建阶段要拉 golang:1.21，运行阶段要拉 alpine:3.19，每个平台一份，速度会被网络拖垮。我的做法是在 Docker daemon 的 /etc/docker/daemon.json 里配置国内镜像加速地址，或者配置自建的 Harbor 作为拉取代理。亲身实测下来，用镜像加速配合 BuildKit 的缓存复用，构建时间能缩短一半以上。
由于多架构构建时，每个平台都要完整拉一遍基础镜像的层，基础镜像的体积会直接乘以平台数量。比如 node:20 的 amd64 版本解压后超过 1GB，arm64 也要 1GB，基础镜像体积翻倍在构建过程中是常态。所以 Dockerfile 里尽量用 alpine 这类精简基础镜像，能省的磁盘和带宽都不少。
3. 可落地的实施步骤
下面进入真正的实操环节。我把从零开始到产出多架构镜像的全过程拆成几个阶段，每个阶段附带我当时怎么判断、怎么调试的思路，方便你直接照着复现。
3.1 环境准备和前置检查
构建机我推荐 Linux，Ubuntu 22.04 或 Debian 12 这类发行版都行。Windows 上虽然也能用 Docker Desktop 配合 WSL2 做多架构构建，但 WSL2 的虚拟化层偶尔会引入一些奇怪问题，尤其是 binfmt_misc 注册在 Windows 侧和 Linux 侧不一致时。如果你和我一样平时主力是 Windows / macOS，我的建议是：别把构建机放在本地，直接在服务器上跑一套 Ubuntu 作为统一的构建环境，省心且可复现。
先确认 Docker 版本。Buildx 插件在 Docker 23.0 之后默认集成了，但保险起见还是看下：
bash复制docker --version
docker buildx version
如果 buildx 命令提示找不到，需要单独安装插件，下载对应平台的二进制文件放到 ~/.docker/cli-plugins/ 目录下，并重命名为 docker-buildx，然后加执行权限即可。
然后检查 binfmt_misc 是否注册成功。最简单的方式是直接跑一个 arm64 的测试容器：
bash复制docker run --rm --platform linux/arm64 alpine uname -m
如果输出是 aarch64，说明 QEMU 模拟链路是通的。如果报 exec format error 或者权限错误，先回头重新执行 binfmt 注册命令，再检查宿主机内核是否开启了 binfmt_misc 支持。我一开始就栽在这里：换了台新构建机，没注册 binfmt，直接跑 buildx 构建 arm64 镜像，报错信息很含糊，后来排查了半天才发现是这一步的锅。
3.2 创建多架构 builder 实例
这一步在上面工具链选型里已经提到，这里再补充几个细节。docker buildx create 创建的 docker-container 类型 builder 会拉取 moby/buildkit 镜像，第一次构建时会自动启动 BuildKit 容器。如果构建机网络不太好，可以先手动拉一次基础镜像，避免创建超时。
创建完成以后，可以查看当前可用的 builder 以及它们支持的平台列表：
bash复制docker buildx ls
如果列出了多个 builder，注意看当前使用标记，也就是带 * 的那个实例。如果构建时 --platform 参数报平台不支持，大概率就是没用对 builder。我在实际工作中见过不少同事直接拿默认 builder 跑多平台构建，要么报错，要么只能构建出当前架构的镜像，很打击士气。
3.3 编写兼容多架构的 Dockerfile
多架构构建的 Dockerfile 本身没有特殊语法，但有一些细节如果写得不注意，会让整个构建流程异常痛苦。
第一个要点是：基础镜像必须带上架构感知能力。大多数官方镜像都支持多架构，直接用 FROM alpine:3.19 就行，BuildKit 会自动根据 --platform 参数选择对应架构。但如果你的项目依赖某些第三方或内部私有镜像，而这些镜像只发布了 amd64 版本，那把 --platform 换成 arm64 时就会直接在 FROM 阶段拉取失败。这时候有两条路：一是要求上游提供多架构版本；二是用 FROM --platform=$BUILDPLATFORM 在构建阶段强制使用当前构建机架构的镜像，运行阶段再切到目标架构。
第二个要点：区分构建阶段和运行阶段。如果你的项目需要在构建阶段编译二进制文件，比如 Go 或 Rust，最好采用多阶段构建。先在一个完整的编译环境里交叉编译出目标架构的二进制，然后把二进制 COPY 到精简的运行镜像里。Go 语言天然支持交叉编译，在 Dockerfile 里设置环境变量就能做到：
dockerfile复制FROM golang:1.21 AS builder
ARG TARGETOS
ARG TARGETARCH
ENV GOOS=${TARGETOS} GOARCH=${TARGETARCH}
WORKDIR /app
COPY . .
RUN go build -o myapp .
FROM alpine:3.19
COPY --from=builder /app/myapp /usr/local/bin/myapp
ENTRYPOINT ["myapp"]
里面用到的 TARGETOS 和 TARGETARCH 是 BuildKit 自动注入的构建参数，分别代表当前 --platform 指定的操作系统和架构。这样编译出的二进制天然就是目标平台的。
第三个要点：不要在一个 Dockerfile 里对不同架构写死不同的安装逻辑。比如有人为了给 arm64 额外装某个包，在 RUN 里写 if [ "$TARGETARCH" = "arm64" ]; then ...，虽然支持，但会显著增加构建复杂度和排错难度。能用多阶段构建拆分架构差异，就不在单层里做条件判断。
3.4 执行一次完整的构建与推送
环境就绪、Dockerfile 就绪后，核心命令其实就一行：
bash复制docker buildx build \
--platform linux/amd64,linux/arm64,linux/arm/v7 \
-t yourregistry.com/yourteam/myapp:1.0.0 \
--push \
.
这行命令的含义是：让 BuildKit 依次或并行构建三个平台的镜像，构建完成后把每个平台的 Manifest 和层全部推送到 Registry，并在 Registry 上生成一个指向三个平台的 Manifest List。
第一次执行时，构建速度会明显偏慢，因为每个平台都要从零解析执行。我当时看到一个有意思的现象：同一个 Dockerfile，amd64 构建只用几分钟，arm64 用 QEMU 模拟则要慢上一大截。这很正常，指令翻译存在天然开销。如果项目依赖安装包数量多、编译工作量大，slow 时间还会进一步拉大。
构建完成后在本地并不会看到对应镜像，因为用了 --push，镜像是直接推送到远端 Registry 的。想验证推送结果的话，可以用：
bash复制docker buildx imagetools inspect yourregistry.com/yourteam/myapp:1.0.0
这个命令会展示该 Tag 下包含的所有平台条目和对应的镜像 digest。我每次推送完都会跑一下这个命令，确认三个平台都齐了再走后续发布流程，算是给发布流程增加一道保险。
如果你想在本地先验证再推送，可以去掉 --push，只构建当前架构的镜像并在本地跑一遍，确认没问题后再执行带推送的完整构建。不过多架构构建时本地验证存在一个坑：docker buildx build 如果指定了多个平台且不带 --push，默认行为是只加载当前平台的内核镜像，其他平台只能以缓存形式存在，无法直接 docker run。想全部落盘，需要加 --output type=docker 或者 --load，但 --load 只支持单平台。所以多平台构建，务实一点就是推送后远端验证。
3.5 把多架构构建接入 CI/CD
我这边最终把这套方案接入了 GitLab CI。具体做法是，在 .gitlab-ci.yml 里定义构建阶段，Runner 使用 Docker executor，并在运行前注册 binfmt、创建 builder：
yaml复制build:
stage: build
tags:
- docker
script:
- docker run --privileged --rm tonistiigi/binfmt --install all
- docker buildx create --name multiarch-builder --driver docker-container --platform linux/amd64,linux/arm64 --use || true
- docker buildx build --platform linux/amd64,linux/arm64 -t ${CI_REGISTRY_IMAGE}:${CI_COMMIT_TAG} --push .
这里有个容易被忽略的问题：GitLab CI Runner 每次任务都是独立容器环境，上一个任务创建的 builder 实例不会保留。所以每个构建任务开头都要执行 binfmt 注册和 builder 创建。为了幂等，builder 创建命令后面我加了 || true，如果同名实例已存在则跳过创建。
如果你用的是 GitHub Actions，思路类似，直接在 workflow 里用官方 docker/setup-buildx-action@v3 和 docker/build-push-action@v6，这两个 action 对多架构构建支持非常完善，底层同样是 buildx + QEMU，action 里连 binfmt 注册都封装好了，比 GitLab 手动配置省事不少。
还有一个点是 CI 里的认证信息。推送到私有 Registry 时，记得在 CI 中先执行 docker login，并把密码以环境变量或 CI Secret 的方式注入。多架构镜像构建过程中，BuildKit 容器需要访问 Registry，所以登录凭证要传给 buildx。我见过有同事直接在脚本里写明文密码，后来改成 GitLab CI 的受保护变量之后才踏实。
4. 常见问题排查与避坑实录
多架构构建方案的坑，基本全都集中在“模拟执行”和“缓存”这两个环节。我把实际操作中遇到的典型问题整理成了一份排查清单，方便你遇到类似报错时快速定位。
4.1 一启动构建就报 exec format error
这是最典型的问题，尤其是在新机器上。现象是构建某个平台的镜像时，RUN 指令里的命令一执行就报类似 exec format error 或 qemu: uncaught target signal 4 (illegal instruction)。
入手思路很简单：确认该平台的可执行格式是否被系统识别。先手动跑一个目标平台的测试容器：
bash复制docker run --rm --platform linux/arm64 alpine uname -m
如果容器能正常输出 aarch64，说明 QEMU 模拟链路没问题，问题主要在 Dockerfile 里。如果容器都跑不起来，那就是 binfmt_misc 没注册或注册不完整。重新注册一次最稳妥：
bash复制docker run --privileged --rm tonistiigi/binfmt --install all
如果重新注册后还是不行，就要检查 Docker Desktop 的虚拟机是否处于旧状态。这个问题我在 Windows 上遇到过，宿主机重启之后 WSL2 的发行版还在，但 binfmt_misc 注册信息丢了。解决办法是：重启 WSL2 或 Docker Desktop 的 Linux 内核，然后重新注册 binfmt。
4.2 QEMU 模拟构建极慢怎么办
模拟执行慢是物理规律，但可以通过几个办法缓解。
第一个办法是增加并发。BuildKit 对多平台构建支持并行执行。如果你有四核 CPU，指定两个平台同时构建，每个平台各占两个核，整体效率比串行构建高很多。默认配置下不加连接限制，BuildKit 通常会自动并行。
第二个办法是合理设计 Dockerfile 的构建阶段。把耗时的依赖安装步骤集中在基础镜像中，提前构建好并推送到私有 Registry，后续项目构建时直接 FROM 私有基础镜像，避免每个平台每次构建都重跑一遍 apt 或者编译依赖。
第三个办法是用原生构建节点替代模拟。如果你的公司同时有 amd64 和 arm64 的机器，可以在 arm64 机器上也配置一个 buildx builder，并把两个 builder 组成一个集群。BuildKit 集群模式下会根据平台自动调度到对应架构的原生机，完全绕开 QEMU 模拟。这是大型团队最推荐的方案，我目前的生产环境就是 x86 和 ARM 机器各一台，构建速度基本和单架构构建持平。
第四个办法是启用 BuildKit 的缓存。多平台构建尽量复用缓存层，不要让每个平台都从零编译。可以在构建命令中加上：
bash复制--cache-from type=registry,ref=yourregistry.com/yourteam/myapp:cache \
--cache-to type=registry,ref=yourregistry.com/yourteam/myapp:cache,mode=max
这样每次构建的层数据会以独立缓存镜像的形式保存在 Registry 中，下次构建直接拉取缓存，跳过未变化的步骤。效果非常明显，尤其是在 GitLab CI 这种每次任务都是全新环境的情况下。
4.3 构建缓存反复失效的真相
很多人以为 BuildKit 缓存和传统 docker build 一样，根据 Dockerfile 指令逐条判断。实际上 BuildKit 的缓存机制更加复杂，它基于指令的哈希值、上下文文件哈希值、构建参数、基础镜像 digest 等多维因素。
多架构构建有一个反直觉的地方：同一段 RUN 指令，不同平台会生成不同的缓存条目。因为基础镜像 digest 不同，平台不同，执行结果不同。所以 --cache-from 引用的缓存镜像必须是按平台分别构建的。用 type=registry 缓存导出时，BuildKit 会自动为每个平台生成独立的缓存记录，这个机制是透明的。
但这里有个关键点：构建命令里一定要保证 --platform 列表完全一致。如果你上一次构建是 linux/amd64,linux/arm64，这一次是 linux/amd64,linux/arm64,linux/arm/v7，前面两个平台的缓存可以用，但整个构建计划变了，部分缓存条目会失效。所以 CI 脚本里 --platform 参数要固定，不要轻易增删。
另外，COPY 指令对缓存的影响最大。如果一个 COPY . . 把整个源码目录拷贝进去，那么即使你只改了一个文件，这层的缓存也会全部失效，后续指令全部重跑。所以 Dockerfile 里尽量精确控制上下文，要么用 .dockerignore 排除无关文件，要么把依赖文件单独提前 COPY，比如：
dockerfile复制COPY go.mod go.sum ./
RUN go mod download
COPY . .
这样的顺序可以最大程度利用依赖缓存。
4.4 镜像推送失败或拉取不到预期架构
推送失败最常见的原因是权限和网络。先确认 docker login 已经执行且凭证有效期足够。BuildKit 容器在推送时使用 buildx 传递的认证信息，如果登录凭证过期或者 CI 变量误传，推送就会 401。排查方法是在日志里找 denied 或 unauthorized 字样。
另一个原因是 Tag 被占用了。同一个 Registry Tag 已经被推送过且不是 Manifest List，再推送多架构镜像时可能产生冲突，报 manifest invalid。解决办法是换个新 Tag，或者先手动删掉旧 Tag 的 Manifest。自建 Harbor 里删除 Manifest 时一定要勾选“同时删除对应的镜像”选项，否则垃圾数据会留在存储里。
拉取不到预期架构的问题则经常出现在超老版本的 Docker Engine 上。比如 18.x 版本的 Docker 对 Manifest List 的支持不完整，拉取时可能只拿到其中一个平台的镜像。遇到这种问题，优先升级客户端和引擎版本。宿主机内核太老也有影响，部分版本的 QEMU 模拟要求内核支持特定 binfmt 特性。
4.5 部分基础镜像不支持目标架构
不是所有镜像都发布了 arm64 版本。有些第三方工具链镜像只提供 amd64，这时候在 FROM 阶段就会失败。我遇到过的一个典型案例是某个内部封装的构建工具，团队一直只发布 amd64 版本。解决办法分几个层面：
- 最简单的是在构建阶段强制用
--platform=$BUILDPLATFORM，也就是用当前机器架构的镜像来运行编译工具，只要最终产物能跨架构输出即可。 - 如果编译工具本身不能交叉编译产物，就需要在目标架构的原生机上构建，或要求工具提供多架构版本。
- 对于运行阶段依赖的基础镜像缺失，没有捷径，只能找替代镜像或者自己构建一份多架构版本。
这里要专门提醒：不要为了省事直接使用 FROM --platform=linux/amd64 强制在 arm64 环境下用 x86 镜像作为运行环境。除非你的容器里通过 qemu-user 模拟运行 x86 进程，否则即使容器起来了，里面的程序也跑不了。我在早期试过这个操作，结果容器能启动但内部程序一执行就报错，绕了很大一圈才明白镜像平台和运行平台必须一致。
4.6 清理与维护经验
多架构构建会消耗大量磁盘空间和网络带宽，长期运行后构建机上会残留很多中间镜像层和 BuildKit 缓存。我的做法是定期执行：
bash复制docker buildx prune
docker builder prune
buildx prune 清理的是 BuildKit 缓存，docker builder prune 是老版遗留命令，两者都执行一遍更彻底。清理间隔根据你的构建频率来定，我这边一般每周清一次。清理后第一次构建会变慢一点，因为缓存被干掉了，但磁盘空间能腾出不少。
有一点要特别留意：BuildKit 的缓存与构建日志里显示的大小并不一致，有时你以为没多少缓存，实际 docker system df 一看几十 GB。所以定期检查 docker system df -v 是很好的习惯，找到占用大户再对症清理。
5. 一些阶段性的心得
多架构镜像构建方案跑通之后，我最大的感受是“工具链不复杂，复杂的是工程习惯”。当我们把每个平台的构建任务统一到一个入口之后，发布流程确实清爽了很多：docker buildx build --platform linux/amd64,linux/arm64 --push 这一条命令，替代了过去两套环境的来回切换。
我个人的习惯是把构建命令固化到 CI 或 Makefile 里，不要在本地手动执行太多次。不是不让大家练手，而是多平台构建容易在本地留下大量中间产物，而且手动操作多了，容易漏掉 binfmt 注册这种前置步骤。尽量让流程自动化，把可变因素降到最低。
最后分享一个小技巧：如果你只是想验证某一条 Dockerfile 指令在多平台下的表现，不用每次都构建完整镜像，可以先 docker buildx build --platform=linux/arm64 --target=某个中间阶段 --load .，这样能快速迭代，省下不少时间。构建精度和速度，其实是可以兼得的，关键是把 Dockerfile 的阶段拆得足够细。