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 | grep -E "(Architecture|Os)" 快速定位
• 注意：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 | jq '.[0].Architecture'
• 常见陷阱：本地构建的镜像没指定 --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 ，看输出里有没有多个 manifests 条目
• 别依赖 FROM ubuntu:22.04 这类基础镜像的“自动适配”——它的 manifest list 里虽有多个架构，但构建过程中的中间层仍可能因架构敏感指令（如汇编、内联 asm）出问题

架构匹配不是“拉得动就算成功”，而是从 pull、build、run 到 push 全链路都要显式声明和验证。最容易被跳过的环节是本地构建后直接 docker push——此时镜像只含单架构，别人在异构机器上拉下来第一秒就失败。