必须用多阶段构建，否则镜像含编译器等冗余工具达800MB+，且因CGO_ENABLED=1默认动态链接libc，导致非静态二进制在scratch中启动失败；需显式设CGO_ENABLED=0、GOOS=linux，并分阶段缓存依赖、精简COPY、选合适运行镜像。
Go 微服务的 Dockerfile 必须用多阶段构建，否则镜像体积大、攻击面宽、启动慢——这不是优化建议，是生产底线。
为什么不能直接 FROM golang:alpine 运行？
很多人图省事写成这样：
FROM golang:1.22-alpine COPY . . RUN go build -o /app . CMD ["/app"]
结果镜像 800MB+，含 Go 编译器、git、apk、shell、调试工具……而你的微服务只需要一个静态二进制文件和证书。运行时还可能因 CGO_ENABLED=1 隐式链接 libc，在 alpine 中看似能跑，换到 scratch 就报 no such file or directory。
- golang:alpine 是构建镜像，不是运行镜像
- 它默认
CGO_ENABLED=1，哪怕你没写 C 代码，net包也会动态链接 - 最终二进制不是静态的，
file ./app输出会含dynamically linked
多阶段构建必须显式控制 CGO_ENABLED 和 GOOS
构建阶段不加这两个环境变量，等于没做多阶段——你只是把编译环境从本地搬进了容器，没解决核心问题。
立即学习“go语言免费学习笔记（深入）”；
-
CGO_ENABLED=0必须显式设置，Go 1.20+ 默认启用 CGO -
GOOS=linux必须指定，否则在 macOS/Windows 上构建会生成 darwin/amd64 二进制 - 推荐命令：
CGO_ENABLED=0 GOOS=linux go build -a -ldflags '-s -w' -o /app/main . -
-a强制重编所有依赖，避免缓存导致的隐式动态链接 -
-s -w去掉符号表和调试信息，体积减少 30%~50%
COPY 只传必要文件，别把整个项目拖进 builder
常见错误是 COPY . . 把 vendor/、testdata/、.git/、README.md 全拷进去。这不仅增大构建缓存体积，还可能触发意外依赖下载或测试执行。
- 先
COPY go.mod go.sum ./，利用 Docker 层缓存加速依赖下载 - 再
COPY cmd/ ./或COPY main.go ./，只传入口文件 - 避免
COPY . .—— 它会让go mod download误读 vendor 目录或间接依赖 - 用
.dockerignore排除node_modules/、.git、docs/等无关目录
运行阶段选 scratch 还是 alpine？看 DNS 和证书需求
scratch 最小（0MB），但没 /etc/resolv.conf、没证书、没 /proc 挂载。很多微服务一跑就报 lookup api.example.com: no such host 或 x509: certificate signed by unknown authority。
- 如果服务只做 HTTP client 调用且需 HTTPS：优先用
FROM gcr.io/distroless/base（含 ca-certificates） - 如果服务要解析域名、查本机 IP、调用
os.Hostname()：用FROM alpine:3.19，体积仅 ~5MB，自带 DNS 配置和基础 libc - 真要用
scratch，必须手动COPY --from=builder /certs/bundle.pem /etc/ssl/certs/ca-certificates.crt，并确保程序里设SSL_CERT_FILE=/etc/ssl/certs/ca-certificates.crt - 无论选哪个，都要加
WORKDIR /app和USER nonroot:nonroot（提前创建用户）
最易被忽略的点：运行阶段没设 WORKDIR，导致 os.Getwd() panic；或监听写成 localhost:8080，容器内根本收不到请求；又或者忘了 EXPOSE 8080，Kubernetes Service 无法正确发现端口。这些都不是“构建成功就能跑”，得逐项验证。
