go多阶段构建是生产部署关键实践，需分离构建与运行环境：第一阶段用golang:alpine编译，显式设置cgo_enabled=0、goos=linux、goarch=amd64生成静态二进制；第二阶段从scratch或alpine仅copy二进制及必要配置（如ca证书），禁用cgo并校验依赖以避免启动失败。
Go 多阶段构建不是语言学习环节，而是生产部署的工程实践。学 Go 时写 go build 能跑通就行；但一上 Docker，不加多阶段，docker images 看到 900MB 镜像，就说明你还没跨过“能跑”和“能上线”的门槛。
为什么初学者写的 Dockerfile 一构建就超 800MB
典型错误是直接用 FROM golang:latest 然后 COPY . . → RUN go build →
CMD ["./app"] <p>这等于把整个 Go SDK、源码、<code>$GOPATH</code></p>、测试依赖、甚至
go tool pprof 全塞进镜像——体积大只是表象，更严重的是：默认 root 运行、含编译器、暴露攻击面、无法复用缓存。
真正该做的，是让构建环境和运行环境物理隔离：
- 第一阶段只负责下载依赖（
go mod download）和编译（go build），用golang:1.22-alpine就够 - 第二阶段从
scratch或alpine:latest开始，只 COPY 编译好的二进制文件 - 中间不保留任何源码、.go 文件、
go.mod、vendor/
CGO_ENABLED=0 不是可选项，是必须项
Go 默认启用 CGO，编译产物会动态链接 libc —— 这在 scratch 镜像里直接 panic，在 alpine 里也可能因 musl 和 glibc 不兼容出问题。
构建命令必须显式关掉：
-
CGO_ENABLED=0：禁用 C 语言互操作，强制纯 Go 静态链接 -
GOOS=linux：避免本地 macOS/Windows 编译产物被误用 -
GOARCH=amd64（或arm64）：匹配目标服务器 CPU 架构 -
-ldflags '-w -s'：去掉调试符号和 DWARF 信息，减小二进制体积
漏掉任意一项，都可能造成容器启动失败，报错如：standard_init_linux.go:228: exec user process caused: no such file or directory（其实是找不到动态库）。
scratch 镜像不是“越小越好”，而是“够用才选”
选 scratch 前先问自己三个问题：
- 代码里有没有用
net.LookupHost或http.Get？→ 需要 DNS 解析能力，scratch没有/etc/resolv.conf和/etc/nsswitch.conf，得手动 COPY - 有没有 HTTPS 请求？→
scratch没 CA 证书，会报x509 certificate signed by unknown authority，得 COPY/etc/ssl/certs/ca-certificates.crt - 要不要进容器 debug？→
scratch没sh、ls、strace，线上出问题只能看日志或改代码重发
如果答“是”，优先用 alpine:latest + apk --no-cache add ca-certificates tzdata；只有确认无外部调用、无调试需求、且已充分测试，才切 scratch。
别忽略 .dockerignore 和构建上下文
即使写了多阶段，如果 .dockerignore 为空，Docker 仍会把整个项目目录（含 node_modules、.git、vendor/、IDE 配置）打包上传给 daemon，拖慢构建速度，还可能意外泄露敏感文件。
最小必要 .dockerignore 内容：
.git.gitignoreREADME.md-
vendor/（除非你用 vendor 模式） **/*.md**/test*
构建命令保持最简：docker build -t myapp . 即可，不用 --build-arg 或 --platform，除非你明确需要交叉编译。
真正的难点不在语法，而在判断：这个二进制到底依赖什么运行时能力？证书、DNS、时区、信号处理……这些不会在 go build 时报错，但会在容器启动后静默失败。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
