Go二进制在Alpine中无法运行是因为默认链接glibc，而Alpine使用musl libc；解决方法是用CGO_ENABLED=0静态编译或改用glibc基础镜像。
为什么 go build 生成的二进制在 alpine 里跑不起来
因为默认 go build 链接的是 glibc，而 alpine 用的是 musl libc。直接把本地编译的二进制扔进 alpine 镜像会报错：standard_init_linux.go:228: exec user process caused: no such file or directory——这其实不是文件不存在，而是动态链接器找不到。
解决方法只有两个：要么用 glibc 基础镜像（如 debian:slim），要么让 Go 编译出静态二进制。后者更轻量，也更符合多阶段构建初衷。
- 加
-ldflags '-s -w'去掉调试信息和符号表 - 加
CGO_ENABLED=0强制静态链接（禁用 cgo 后，net、os/user 等包行为有细微差异，但对 HTTP 服务类应用通常无感） - 完整命令示例：
CGO_ENABLED=0 go build -ldflags '-s -w' -o myapp .
多阶段构建中 builder 阶段该不该用 golang:alpine
不该。golang:alpine 镜像里没有 git、ca-certificates 等工具，很多依赖 git 获取的 module（比如私有仓库或带 commit hash 的 replace）会拉取失败；HTTPS 请求也可能因证书缺失而超时。
更稳妥的选择是 golang:1.22-slim（基于 debian slim），它体积不大（约 350MB），自带基础工具链和证书，兼容性好，build 阶段的耗时和稳定性都更可控。
立即学习“go语言免费学习笔记（深入）”；
- 如果坚持用 alpine builder，必须手动
apk add --no-cache git ca-certificates -
golang:alpine的 go version 常滞后于主流版本，升级不及时 - 某些 cgo 依赖（如 sqlite、pq）在 alpine 上需额外编译，反而增加复杂度
FROM scratch 镜像启动失败的三个常见原因
scratch 是空镜像，连 /bin/sh 都没有，所以任何依赖 shell、动态库、配置文件或 /etc/resolv.conf 的操作都会挂掉。HTTP 服务看似简单，实则暗坑不少。
- Go 程序若用了
net.LookupHost或http.DefaultClient，默认会读/etc/resolv.conf和/etc/nsswitch.conf——scratch里没有，得显式挂载或用net:ipnetwork模式启动容器 - 程序日志写到
/var/log/xxx？路径不存在，会 panic。建议全用 stdout/stderr 输出 - 没设
WORKDIR又在代码里用了相对路径打开文件？当前目录是/，但scratch里啥也没有
验证是否真能跑：用 docker run --rm -it your-image /your-binary --help，别等部署到 k8s 才发现进不去容器。
如何确认最终镜像里没留 build 时的源码和依赖
多阶段构建容易“漏东西”：比如 COPY 时用了 . 而不是 ./cmd/myapp，或者忘记在 final 阶段清除 go.mod go.sum，甚至把 .git 目录一起塞了进去。
最直接的办法是运行镜像后进容器看一眼：
docker run --rm -it your-final-image sh -c 'ls -la / && find / -name "*.go" -o -name "go.mod" -o -name ".git" 2>/dev/null'
- final 阶段只应有：二进制、必要配置文件（如
config.yaml）、证书（如需 TLS） - COPY 时优先用
COPY --from=builder /workspace/myapp /myapp，而不是COPY --from=builder /workspace/ / - 如果用了
go mod vendor，vendor 目录只应在 builder 阶段存在，final 阶段不需要
镜像小不是目的，小且干净、可复现、无冗余才是关键。尤其当镜像要进私有 registry 或被审计时，多一个 .DS_Store 文件都可能触发告警。
