Docker容器一启动就退出，日志里只留下 exec format error，很多人会先怀疑镜像坏了。这个报错更常见的原因其实是CPU架构不匹配：服务器运行在AMD64平台，拉到的却是ARM64镜像，或者在苹果芯片电脑构建的镜像没有包含AMD64版本。
不过，架构不是唯一答案。入口脚本缺少正确的shebang、使用Windows换行符，甚至镜像里指定了无法执行的文件，也可能得到相同错误。我处理这类问题时，会先确认错误发生在二进制程序还是脚本，再决定重拉镜像、重新构建还是修正入口文件。
先保存容器退出信息
不要反复执行重启命令覆盖现场，先查看容器状态、退出码和完整日志：
docker ps -a --no-trunc
docker inspect CONTAINER --format '{{json .State}}'
docker logs --timestamps --tail 200 CONTAINER容器在创建后立即退出，日志包含 exec /path/to/file: exec format error，说明内核无法按当前格式执行入口文件。把报错中的实际路径记录下来，它决定下一步检查镜像架构还是脚本内容。
还要确认最终生效的Entrypoint和Cmd。Dockerfile、镜像元数据和Compose文件都可能覆盖启动命令，不能只看项目目录中的Dockerfile。
docker inspect IMAGE --format '{{json .Config.Entrypoint}} {{json .Config.Cmd}}'
docker inspect CONTAINER --format '{{json .Path}} {{json .Args}}'核对服务器与镜像架构
先查看宿主机和Docker守护进程识别的架构：
uname -m
docker info --format '{{.OSType}}/{{.Architecture}}'x86_64通常对应 linux/amd64，aarch64或 arm64对应 linux/arm64。随后检查本地镜像：
docker image inspect IMAGE --format '{{.Os}}/{{.Architecture}}'主机是AMD64而镜像为ARM64，或两者相反，已经足以解释多数二进制程序的exec format error。镜像标签相同也不能证明架构相同，构建者可能把同一个标签重新推送为单一平台版本。
检查远程镜像是否支持多平台
公开镜像常通过manifest list同时提供多个架构，Docker会按当前平台自动选择。可以查看远程标签包含哪些平台：
docker buildx imagetools inspect REGISTRY/IMAGE:TAG输出中存在 linux/amd64和 linux/arm64，说明这是多平台镜像；只出现一个平台，则其他架构的主机无法原生运行。私有仓库权限不足时，该命令可能只返回认证错误，不应把认证问题误判为镜像缺少平台。
重新拉取前可以删除本地错误标签，或明确指定平台验证，但指定平台不等于自动获得模拟能力：
docker pull --platform linux/amd64 REGISTRY/IMAGE:TAG
docker run --rm --platform linux/amd64 REGISTRY/IMAGE:TAG COMMAND重新构建正确平台镜像
镜像由自己构建时，应在构建阶段声明目标平台。先确认Buildx builder状态：
docker buildx ls
docker buildx inspect --bootstrap构建单一AMD64版本可以使用：
docker buildx build --platform linux/amd64 -t REGISTRY/APP:TAG --push .同时服务两种架构时，可构建多平台manifest：
docker buildx build --platform linux/amd64,linux/arm64 -t REGISTRY/APP:TAG --push .多平台构建是否成功还取决于基础镜像、编译工具链和依赖包。某个基础镜像只有AMD64版本时，Buildx不会凭空生成ARM64软件包。编译型应用还要确认目标架构产物，而不是把构建机上的二进制直接复制进所有平台镜像。
架构一致时检查入口脚本
主机与镜像架构一致，错误路径又指向 .sh脚本时，应检查脚本首行、换行格式和执行权限。可以从镜像中复制脚本，或覆盖入口进入shell后检查：
file entrypoint.sh
sed -n '1,3l' entrypoint.sh
ls -l entrypoint.sh首行应指向镜像中真实存在的解释器，例如 #!/bin/sh。Windows的CRLF换行会让解释器路径末尾带上不可见的回车字符，表现为无法执行或找不到文件。修正后应重新构建镜像，避免只在运行中的容器里临时修改。
脚本没有执行权限时更常见的是permission denied，但不同入口组合可能让报错信息混杂。还要检查脚本是否为空、是否被错误编码保存，以及基础镜像是否真的包含bash。
不要盲目依赖跨架构模拟
QEMU和binfmt可以让部分ARM64镜像在AMD64主机上运行，反向也类似，但它们并不是生产环境的默认修复。模拟会增加CPU开销，部分系统调用、原生扩展和性能敏感程序仍可能失败。
先检查主机是否已经注册对应解释器，再决定是否用于构建或短时验证。直接在Compose中添加 platform只会声明目标平台，不会自动安装模拟器。
需要对比AMD64与ARM64行为时，可以在 萤光云 建立隔离环境，也可以利用按小时计费的 LightNode 分别准备对应架构的云服务器。测试镜像不要携带生产密钥、数据库备份或真实用户数据。
修复后怎样验收
重新构建或更换镜像后，先核对镜像摘要和平台，再启动一个一次性容器验证入口程序：
docker image inspect IMAGE --format '{{.Id}} {{.Os}}/{{.Architecture}}'
docker run --rm IMAGE COMMAND
docker run --name app-check IMAGE正式替换前还要验证健康检查、端口监听、依赖连接和容器重启策略。镜像能启动不代表所有原生依赖都适配了目标架构，尤其要测试数据库驱动、图像处理库和浏览器组件。
合格的修复应明确主机、镜像和应用二进制三者的架构，并保证镜像在目标平台重新拉取后仍能稳定启动。
常见问题
在Compose里写platform就能解决吗？
只能让Docker选择指定平台镜像。宿主机没有对应架构或模拟支持时，容器仍然无法运行，生产环境更适合使用原生平台镜像。
为什么在苹果芯片电脑正常，部署到服务器就报错？
本地可能构建了ARM64镜像，或者Docker Desktop自动使用了模拟器；服务器是AMD64且没有模拟能力时，问题才会暴露。
镜像架构一致为什么仍然报错？
继续检查Entrypoint脚本的shebang、CRLF换行、执行权限和解释器路径，错误也可能来自脚本而不是ELF二进制架构。
