Go二进制静态编译+多阶段构建是最优镜像策略，用golang:alpine构建、scratch或alpine:latest运行，可压至10MB内并规避root和CGO问题；单阶段使用golang:latest会导致900MB以上镜像、root权限风险及非生产就绪问题。
直接用 golang:latest 构建并运行 Go 应用，镜像会超过 900MB，且默认以 root 运行、带完整工具链——这不是部署，是埋雷。
为什么多阶段构建不能省略
单阶段构建把 go build、go mod、源码、测试依赖全塞进最终镜像，体积膨胀、权限失控、攻击面扩大。多阶段不是“可选优化”，而是生产环境的准入门槛。
- builder 阶段只做三件事：
go mod download、COPY . .、CGO_ENABLED=0 GOOS=linux go build -ldflags="-s -w" -o binary . - 运行阶段必须换基础镜像，
FROM alpine:latest或FROM gcr.io/distroless/static-debian11，不能沿用golang:* -
COPY --from=builder只复制二进制，不带/go、/usr/local/go、git、sh等任何非运行必需项
alpine vs scratch：选哪个取决于你调了哪些系统功能
scratch 镜像确实只有 0B，但没 /etc/resolv.conf 就 DNS 失败，没 /etc/ssl/certs/ca-certificates.crt 就 TLS 握手失败——这些不是编译问题，是运行时缺失。
- 用
alpine:latest：加RUN apk --no-cache add ca-certificates tzdata，够用且调试方便 - 用
scratch：必须显式COPY --from=builder /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/，还要手动补/etc/resolv.conf和时区文件，稍有遗漏就 panic - 如果你用了
net/http+ HTTPS、time.LoadLocation、或任何依赖/proc//sys的库，scratch就不是“更小”，而是“不可用”
GOOS=linux 和 CGO_ENABLED=0 不是万能钥匙
它们确保二进制不链接宿主机 libc，但无法绕过运行时环境依赖。Go 标准库很多行为是动态适配的，比如：
立即学习“go语言免费学习笔记（深入）”；
-
net.LookupHost会查/etc/nsswitch.conf和libnss_dns.so（musl 下走不同路径） -
http.DefaultTransport默认启用 HTTP/2，需要 ALPN 支持，而 Alpine 的 OpenSSL 版本可能不兼容 -
os/user.Lookup、os/exec.Command在scratch里直接 panic，因为连/bin/sh都没有
所以别迷信“静态编译=开箱即用”，先跑通 curl -v https://httpbin.org/get 和 date -R 再上线。
构建缓存失效是镜像变大的隐形推手
Docker 层缓存非常敏感，COPY . . 放在 go mod download 前面，每次代码改一行，整个依赖层就得重拉——构建时间翻倍，镜像层数暴增。
- 固定顺序：
COPY go.mod go.sum ./→RUN go mod download→COPY . .→RUN go build - 如果项目用了
vendor，COPY vendor ./vendor要放在go mod download之后，否则缓存无效 - 本地开发时加
--cache-from指向 CI 构建的中间镜像，能跳过 builder 阶段大部分耗时操作
真正难的不是写对第一版 Dockerfile，而是当某天服务突然报 lookup xxx: no such host 时，你能立刻判断是缺证书、缺 resolv.conf，还是 musl 兼容性问题——而不是回退到 golang:latest 临时救火。
