Go默认动态链接glibc，而Alpine用musl libc，导致二进制无法运行；应禁用cgo静态编译（CGO_ENABLED=0 go build -a -ldflags '-s -w'），多阶段构建需显式命名builder阶段，慎用scratch镜像。
为什么 go build 默认产出的二进制在 Alpine 镜像里跑不起来
因为 Go 默认编译出的是动态链接的可执行文件，依赖宿主机的 libc（比如 glibc），而 Alpine 用的是 musl libc。直接拷进去会报 no such file or directory——其实不是文件丢了，是动态加载器（/lib64/ld-linux-x86-64.so.2）根本不存在。
- 临时解决：用
golang:alpine基础镜像编译，但得确保所有依赖（比如 cgo）都兼容 musl - 更稳方案：禁用 cgo，静态编译：
CGO_ENABLED=0 go build -a -ldflags '-s -w' -o app . -
-s去掉符号表，-w去掉 DWARF 调试信息，两者合起来通常能减掉 30%~50% 体积
多阶段构建中 FROM ... AS builder 的命名不是可有可无
名字决定了你在后续阶段能不能正确 COPY --from=builder。没起名或名字拼错，Docker 就找不到上一阶段的产物，构建时不会报错，但 COPY 会静默失败（目标路径为空），最后运行镜像就提示 command not found。
- builder 阶段必须显式命名，比如
FROM golang:1.22 AS builder - 生产阶段用
FROM alpine:3.19后，COPY --from=builder /app/app /usr/local/bin/app才有效 - 别用数字序号（如
--from=0）引用阶段，重构时极易断掉
scratch 镜像里连 /dev/null 都没有，日志和信号处理会出问题
很多人图极致精简直接选 FROM scratch，结果程序启动后立刻崩溃，或者 kill -15 无法优雅退出。因为 scratch 是空镜像，没设备节点、没基础目录、甚至没 /tmp，Go 程序某些默认行为（比如写临时文件、查 /proc）会失败。
- 优先用
FROM alpine:3.19替代scratch，体积只多 2~3MB，但稳定得多 - 真要用
scratch，得手动mkdir -p /tmp和touch /dev/null（通过RUN不行，得用ONBUILD或提前挂载，实际很麻烦） - Go 程序若调用了
os.UserHomeDir()或os.Getwd()，在scratch里大概率 panic
go mod vendor 不是必须的，但能规避构建时网络和代理问题
多阶段构建中，builder 阶段拉 module 往往卡在公司内网、CI 代理或 GOPROXY 不一致上。本地 go run 没问题，Docker 构建却超时，八成是模块下载环节掉了链子。
立即学习“go语言免费学习笔记（深入）”；
- CI 环境建议加一步：
go mod vendor，然后COPY go.mod go.sum vendor/ ./，再go build -mod=vendor -
-mod=vendor强制只读 vendor 目录，不碰网络，也不受GOPROXY影响 - 注意：vendor 后要 git commit，否则 Docker 构建时 COPY 不到内容
/var/log、甚至只是某条 exec.Command("sh", "-c", ...) 在 scratch 里直接失效。这些地方不跑一遍真实构建流程，光看文档很难暴露。 
