ARCH 和 OS 信息需通过 docker inspect 查看 Architecture 和 Os 字段；拉取镜像时须用 --platform 显式指定架构，否则默认按宿主机匹配；运行报 “exec format error” 即架构不匹配，应检查 uname -m 与 inspect 结果。
docker images 显示的 ARCH 和 OS 是怎么看出来的
执行 docker images 默认不显示镜像架构信息，你看到的只是镜像名、标签、ID、大小——ARCH 和 OS 被藏在底层元数据里。真要确认镜像是否适配当前 CPU（比如 Apple Silicon 的 arm64 vs Intel 的 amd64），得用 docker inspect 查 Architecture 和 Os 字段。
- 运行
docker inspect <image-name> | grep -E "(Architecture|Os)"</image-name>快速定位 - 注意：
Os多为linux，但Architecture才决定能否在本地 CPU 上原生运行 - 有些镜像（如官方
alpine）会同时发布amd64和arm64变体，但docker images不体现多平台差异
拉取镜像时怎么指定 CPU 架构（避免默认拉错）
Docker CLI 默认按宿主机架构拉取，但如果你在 M1 Mac 上想跑 x86_64 镜像，或在 CI 服务器上需要强制拉 arm64 版本，就得显式指定 --platform 参数，否则可能拉到不兼容的变体，甚至静默 fallback 到模拟层（影响性能）。
- 拉 arm64 镜像：
docker pull --platform linux/arm64 nginx:alpine - 拉 amd64 镜像（在 arm64 宿主机上）：
docker pull --platform linux/amd64 python:3.9-slim - 不加
--platform时，Docker 会查manifest list并选匹配宿主机的条目；若无匹配项，可能报错no matching manifest for linux/arm64 -
--platform必须在pull阶段指定，run时设了也没用（镜像已经拉下来了）
docker run 报 “exec format error” 怎么快速定位
这是典型的架构不匹配错误，本质是容器试图在不兼容的 CPU 上执行二进制文件。不是权限问题，也不是路径错误，别花时间 chmod 或改 CMD。
- 先确认宿主机架构：
uname -m（输出aarch64或x86_64） - 再查镜像实际架构：
docker inspect <image-id> | jq '.[0].Architecture'</image-id> - 常见陷阱：本地构建的镜像没指定
--platform，BuildKit 默认按 build 机架构打，推送到 registry 后别人拉下来就可能错 - 如果用
docker buildx build，必须加--platform linux/amd64,linux/arm64才能生成多架构镜像
CI/CD 流水线里怎么保证镜像架构稳定
流水线机器类型（如 GitHub Actions 的 ubuntu-latest 默认是 amd64，但 macos-latest 是 arm64）会影响构建结果。不显式约束，同一份 Dockerfile 在不同节点产出的镜像架构可能不一致。
- 在
docker build命令中固定--platform，例如：docker build --platform linux/amd64 -t myapp . - 启用 BuildKit（
export DOCKER_BUILDKIT=1）后，--platform才真正生效；旧版 daemon 会忽略它 - 检查 registry 中镜像是否多架构：用
docker buildx imagetools inspect <image></image>，看输出里有没有多个manifests条目 - 别依赖
FROM ubuntu:22.04这类基础镜像的“自动适配”——它的 manifest list 里虽有多个架构，但构建过程中的中间层仍可能因架构敏感指令（如汇编、内联 asm）出问题
架构匹配不是“拉得动就算成功”，而是从 pull、build、run 到 push 全链路都要显式声明和验证。最容易被跳过的环节是本地构建后直接 docker push——此时镜像只含单架构，别人在异构机器上拉下来第一秒就失败。
