Go应用Docker容器内启动报no such file or directory错误排查

exec /app: no such file or directory报错并非指/app二进制文件本身不存在，而是二进制依赖的动态链接加载器在运行时镜像中缺失，内核无法加载程序时抛出的误导性提示。
从你提供的file /app输出可以明确两个关键信息：

• 编译出的二进制为动态链接版本，而非静态编译
• 程序指定的动态加载器路径为/lib/ld-musl-x86_64.so.1，属于musl libc的加载器

你的构建阶段使用golang:1.18-alpine基础镜像，Alpine发行版默认采用musl libc，开启cgo的情况下Go编译会默认动态链接系统musl库；但运行阶段使用的gcr.io/distroless/static-debian11、普通Debian镜像均为glibc生态，系统内不存在musl加载器文件，最终触发该错误。你之前尝试添加GOOS、GOARCH、指定平台参数无法解决问题，因为架构、系统类型配置本身没有错误，问题核心是libc生态不匹配。

根据实际场景选其一即可：

方案1：编译纯静态二进制（最推荐，适配distroless/scratch等极简镜像） #

在构建阶段的编译命令中关闭cgo，强制Go生成无系统动态库依赖的静态二进制：
将原有构建命令

RUN go build -o /app

修改为

RUN CGO_ENABLED=0 go build -o /app

关闭cgo后Go会将所有依赖静态编译进二进制文件，不再依赖任何系统libc和动态加载器，可直接在distroless static、scratch等无libc的极简镜像中运行。

方案2：统一构建与运行阶段的libc生态 #

如果你的程序依赖必须开启cgo的第三方组件（比如部分SQLite驱动、系统级调用库），无法静态编译，可通过两种方式统一libc版本：

• 调整构建阶段基础镜像：将build阶段的golang:1.18-alpine替换为Debian系的golang:1.18-bullseye，该镜像默认使用glibc，编译出的二进制依赖glibc加载器，和Debian、distroless static-debian11等运行时镜像完全匹配。
• 调整运行阶段基础镜像：保留Alpine构建环境的话，将运行时镜像替换为Alpine基础镜像或distroless的musl变体，保证系统内存在/lib/ld-musl-x86_64.so.1加载器即可。

重新构建镜像后，可通过file /app命令检查二进制属性，若输出包含statically linked标识，说明静态编译生效，不会再出现该加载错误。

内容的提问来源于stack exchange，提问作者Steffen