根本原因是Go二进制默认动态链接glibc，而Alpine使用musl libc；解决方法是构建时显式设置CGO_ENABLED=0，生成真正静态链接的二进制。
根本原因不是文件“找不到”，而是动态链接器缺失：go 默认编译出的二进制依赖 glibc 的动态链接器（如 /lib64/ld-linux-x86-64.so.2），而 alpine 使用的是 musl libc，压根没这个路径、也没这个文件。
用 ldd 确认依赖到底是什么
进 Alpine 容器执行：ldd ./your-binary。如果看到输出里有 /lib64/ld-linux-x86-64.so.2 或 libc.so.6 指向 /lib64/，就坐实了问题——Alpine 根本没有 /lib64 目录，musl 的链接器在 /lib/ld-musl-x86_64.so.1。
- 别信
file ./your-binary显示 “statically linked” 就安全：Go 1.19+ 默认禁用 CGO 后才可能真静态；只要CGO_ENABLED=1（默认值），哪怕没写 C 代码，也会悄悄链接glibc -
ldd在 Alpine 上对 Go 二进制有时会报 “not a dynamic executable”，这不是好事——说明它连解析都失败了，恰恰印证是链接器不兼容
CGO_ENABLED=0 是最可靠解法
必须在构建阶段显式关闭 CGO，强制 Go 使用纯 Go 实现的标准库（如 DNS 解析走 netgo），产出真正静态链接的二进制。
- 正确写法：
CGO_ENABLED=0 go build -a -ldflags '-s -w' -o app .（-a强制重编译所有依赖，-s -w减体积） - 错误写法：
go build -ldflags '-extldflags "-static"'—— Go 不支持这种 C 链接器参数，会被忽略 - 别在运行时补救：临时在 Alpine 里
mkdir /lib64 && ln -s /lib/libc.musl-x86_64.so.1 /lib64/ld-linux-x86-64.so.2属于 hack，不保证所有符号兼容，且破坏镜像不可变性
多阶段构建中 builder 阶段不能省 CGO_ENABLED=0
即使你用了 golang:alpine 作为 builder 镜像，也不能默认安全——因为 golang:alpine 里 CGO_ENABLED 默认仍是 1，只是它装的是 musl 版的 gcc，能编译但产物仍可能动态链接 musl（若项目含 cgo 依赖）；而多数服务根本不需要 cgo。
- builder 阶段务必写死：
ENV CGO_ENABLED=0或每条go build前加前缀 - 慎用
scratch：虽然最小，但没/bin/sh、没日志输出能力；alpine镜像（~5MB）已足够轻量，还保留调试基础 - 验证方式：构建完拷进 Alpine 容器，直接
./app运行，不报no such file or directory即过关
最容易被忽略的一点：本地开发机（macOS/Linux）上 go build 默认启用 CGO，直接拷进 Alpine 必跪；CI/CD 流水线里哪怕用了 Alpine builder 镜像，也得检查 CGO_ENABLED 是否真的关了——它不会自己猜你想要什么。
