直接用 scratch 镜像跑 Go 程序会 panic，因启用 cgo 时依赖 libc/NSS，而 scratch 无动态链接器；需设 CGO_ENABLED=0 强制静态编译，并用 ldd 验证“not a dynamic executable”。
为什么直接用 scratch 镜像跑 Go 程序会 panic？
Go 编译出的二进制默认是静态链接的，但若用了 cgo（比如调 DNS、读 /etc/resolv.conf、用 net/http），就会依赖系统 libc 和 NSS 库。直接扔进空的 scratch 镜像，运行时大概率报 standard_init_linux.go:228: exec user process caused: no such file or directory——不是找不到二进制，而是找不到动态加载器或 libc 符号。
- 检查是否启用了 cgo：
CGO_ENABLED=1 go build是默认行为；CGO_ENABLED=0 go build才强制纯静态 -
net包在 Linux 上默认走 cgo（为支持getaddrinfo）；加os/user、os/signal等也容易触发 - 用
ldd your-binary查依赖：输出 “not a dynamic executable” 才算真正静态
怎么确保 Go 二进制能在 scratch 里跑起来？
核心就一条：关掉 cgo，且避免隐式依赖系统设施。不是“编译能过”就行，得验证运行时行为。
- 构建前设环境：
CGO_ENABLED=0 GOOS=linux go build -a -ldflags '-extldflags "-static"' -o myapp . -
-a强制重编所有依赖（包括标准库），防止缓存了带 cgo 的包 -
-ldflags '-extldflags "-static"'是保险项，对某些旧版 Go 更稳妥 - 启动前检查：
docker run --rm -v $(pwd):/app ubuntu:22.04 ldd /app/myapp，确认无输出 - Dockerfile 示例：
FROM scratch COPY myapp / CMD ["/myapp"]
什么时候该退一步用 alpine 而不是 scratch？
不是所有 Go 程序都能干净地关掉 cgo。调试、日志轮转、证书验证、甚至某些云 SDK 内部调用系统调用时，会悄悄拉起 cgo。硬上 scratch 只会让错误延迟到运行时才暴露。
- 典型踩坑场景：
http.DefaultClient在 Alpine 上 DNS 解析失败（glibc vs musl 行为差异）、crypto/x509找不到 CA 证书路径 - Alpine 镜像体积仍很小（~5MB），但自带
musl、ca-certificates、基础/etc结构 - 推荐写法：
FROM alpine:latest RUN apk --no-cache add ca-certificates WORKDIR /root/ COPY myapp . CMD ["./myapp"]
- 如果必须用 Alpine 且用了 cgo，记得
apk add gcompat（兼容部分 glibc 符号），但这是权宜之计，不是长期方案
镜像瘦身还有哪些被忽略的细节？
很多人只盯着基础镜像大小，却忘了 Go 二进制本身可能带调试符号、未裁剪的模块，或者 Docker 构建层残留中间文件。
- 编译时加
-ldflags "-s -w"：去掉符号表和 DWARF 调试信息，体积常减 30%+ - 用
upx压缩（谨慎）：upx --best myapp，但会增加启动时间，某些安全策略禁止 - Docker 构建用多阶段：
builder阶段装 Go 环境，final阶段只 COPY 二进制，避免把$GOPATH或缓存塞进镜像 - 别忽略
.dockerignore：排除go.mod、vendor/、测试文件等，防止意外 COPY 大文件
真正最小化不是选 scratch 就完事，而是看你的程序实际依赖什么。cgo 开关、证书路径、DNS 行为、信号处理——这些地方一动，镜像策略就得跟着变。
