Go程序在开发机上跑得好好的，传到服务器或者塞进容器就起不来，最常撞见的是两行报错。
bash: ./app: cannot execute binary file: Exec format error
standard_init_linux.go:228: exec user process caused: no such file or directory
两行都像在说文件坏了。第一行其实跟CPU架构有关，第二行是二进制依赖的动态链接库在目标环境里找不到。方向不一样，混在一起查会白花半天。
先把目标机器的架构问清楚
别凭印象，敲一条命令就知道了。
uname -m
file ./app
x86_64对应amd64，aarch64对应arm64，armv7l对应arm并且要额外带GOARM=7，i686对应386。这几个对应关系记不住就每次敲uname，比猜快得多。file命令的输出更直接，它会把ELF、架构、是否stripped、是否动态链接一股脑打出来。
交叉编译就三行
GOOS=linux GOARCH=amd64 go build -o app ./cmd/app
Windows的cmd不支持这种环境变量前缀写法，得先set再build。
set GOOS=linux
set GOARCH=amd64
go build -o app ./cmd/app
苹果芯片的开发机器上，go env里GOOS默认值是darwin、GOARCH是arm64，不显式指定GOOS=linux，编出来的就是macOS的可执行文件，丢到Linux上必然是Exec format error。这个坑踩过不止一次，看报错还以为是文件传坏了。
go env -w GOOS=linux这种全局写法不推荐，改完容易忘，下次编译本地工具又得改回来。每次build前挂在命令行上，一个月也碰不到一次误伤。
no such file or directory那一半是动态链接
Go在用到net、os/user这些包的时候会走cgo，编出来的二进制是动态链接的，运行时要靠目标机器上的glibc。开发机是Ubuntu，目标镜像是Alpine，musl和glibc不是一回事，容器启动就抛standard_init_linux.go那一行。Alpine 3.19、3.20、3.21，这几个版本带的musl libc小版本都不一样，但结论一致：glibc编的东西在musl上跑不了。
判断方式还是file命令。输出里写statically linked就没事，写dynamically linked并且interpreter是/lib64/ld-linux-x86-64.so.2，说明它要在目标机器上找这个解释器，找不到就报no such file or directory。报错里那个no such file指的不是app本身，是解释器。
缺哪个库，ldd列得清清楚楚。
ldd ./app
输出里带not found的那几行就是答案，常见的有libc.so.6和libpthread.so.0。glibc 2.36、2.37、2.38，之间还有符号版本差异，server上是Debian 11而编译机是Ubuntu 24.04的时候，可能碰到GLIBC_2.34 not found这种更具体的提示，同一类问题。
关掉cgo，编出静态二进制
CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -ldflags "-s -w" -o app ./cmd/app
Go 1.20、1.21、1.22、1.23，这几个版本上这条命令行为一致，编完再跑file，输出会变成statically linked。实测一个一万两千行的项目，加-ldflags "-s -w"之后体积从11.2MB降到7.4MB，启动耗时没变化。
scratch和distroless镜像必须静态
Dockerfile里FROM scratch或者gcr.io/distroless/static的镜像，里面连/bin/sh都没有，动态链接的二进制放进去一定跑不起来。FROM alpine同理。
FROM scratch
COPY app /app
ENTRYPOINT ["/app"]
非要用alpine的话还有一条路，装build-base之后走外部链接器静态编，参数长、还容易踩到DNS解析回退到纯Go实现的问题。实测下来直接CGO_ENABLED=0省事得多，编出来的东西放进哪个镜像都行。
不能关cgo的场合
项目里用了mattn/go-sqlite3，或者依赖C写的加解密、图像处理库，CGO_ENABLED=0会直接编译失败，报的是一堆找不到头文件的错误。这种只能保证目标镜像里装好对应的运行库，或者把基础镜像从alpine换成debian:bookworm-slim。换镜像比在alpine上折腾musl-dev划算，镜像大几十MB而已。
还有一种情况是文件真的坏了
报错同样是exec format error，但架构对、链接方式也对，那多半是传输过程把二进制改了。FTP忘了切二进制模式、Git的autocrlf把换行换成CRLF，都会走到这一步。
file ./app
md5sum ./app
两边md5对不上就重传。传二进制一律用scp或者rsync，别用FTP的自动模式，那是给文本文件准备的。Shell脚本被autocrlf改掉的时候报错是/bin/sh^M: bad interpreter，同一个来源，改core.autocrlf为input就能断根。
排查顺序压成一句话：uname看架构，file看链接方式，ldd看缺什么库。三步走完，这两行报错基本都能定位，剩下的就是补一个CGO_ENABLED=0或者换一对GOOS与GOARCH。数据截至2026年9月，Go的稳定版已经到1.23。