多阶段构建可将Go应用镜像从900MB+压缩至12–20MB，核心是构建阶段用golang镜像编译，运行阶段仅COPY静态二进制到scratch或alpine镜像，剔除SDK、缓存、源码等冗余内容。
Go 应用最终镜像体积超过 300MB，基本可以断定没用多阶段构建，或者用了但写法有误。真正精简的 Go 镜像应该稳定在 12–20MB 区间——这不靠压缩，而是靠构建逻辑隔离。
为什么FROM golang不能直接作为生产镜像
因为 golang:1.25-alpine 这类镜像本质是开发环境：它包含 go、git、gcc（哪怕 CGO 关闭）、pkg-config 等全套工具链，体积约 300–900MB。运行时完全不需要这些。更危险的是，如果 COPY . . 放在 RUN go build 之前且没清理，源码、go.sum、甚至 .git 目录都会留在最终层里。
- 镜像扫描常报高危漏洞，多数来自
glibc或apk工具本身，而非你的代码 -
docker history会显示几十层，其中大块是go mod download缓存和中间构建产物 - Kubernetes Pod 启动慢，不是因为二进制加载，而是因为拉取几百 MB 镜像耗时
COPY --from=builder 的路径必须精确匹配构建阶段输出位置
常见错误是阶段一编译出的二进制放在 /app/myapp，阶段二却写 COPY --from=builder /app/myapp /usr/local/bin/myapp，结果容器启动报 exec: "./myapp": stat ./myapp: no such file or directory——其实是因为 CMD 指定路径和实际位置不一致，或 WORKDIR 未对齐。
- 阶段一的
WORKDIR和RUN go build -o路径要明确，推荐统一用绝对路径，比如RUN go build -o /build/app - 阶段二的
COPY --from=builder必须完整复现源路径，不能依赖相对路径推导 - 如果用
alpine做基础镜像，确保二进制是CGO_ENABLED=0静态链接的，否则会缺libc报错
alpine 不是唯一选择，但要注意 ssl_ca_certs 和时区
用 alpine:3.18 是主流，但它默认不含 CA 证书和 /etc/timezone，Go 程序发 HTTPS 请求或调用 time.Now() 可能失败或返回 UTC 时间。
立即学习“go语言免费学习笔记（深入）”；
- 补证书：加一行
RUN apk add --no-cache ca-certificates - 设时区：加
ENV TZ=Asia/Shanghai并RUN ln -sf /usr/share/zoneinfo/${TZ} /etc/localtime - 替代方案可选
scratch（极致精简），但要求二进制完全静态、无动态依赖，连日志输出都得自己处理；也有人用distroless/static，它比scratch多带证书和用户管理能力
构建参数和 Git 元信息注入容易被忽略
很多团队只关心体积，却忘了构建产物该带版本号、Git 提交哈希、编译时间等元信息——它们不在镜像体积里，但对可观测性和问题回溯至关重要。这些必须在构建阶段注入，运行阶段无法补。
- 用
-ldflags "-X main.GitCommit=$(git rev-parse --short HEAD)"注入，注意命令替换要在构建阶段执行，不是 Dockerfile 解析时 - 避免在
RUN中用$(date)等 shell 扩展导致缓存失效；可先ENV BUILD_TIME=$(date ...)再引用 - 如果 CI 流水线中 Git 仓库被 shallow clone，
git rev-parse可能失败，建议加兜底：|| echo "unknown"
最易被跳过的其实是构建阶段的 go mod download 分离：把 go.mod 和 go.sum 单独 COPY 并 RUN go mod download，才能让这一层缓存复用，否则每次改一行代码都会重下所有模块。
