Go多阶段构建能减小镜像体积，因其利用静态编译产物与阶段隔离：编译阶段用golang镜像，运行阶段仅保留静态二进制至scratch或alpine，避免携带编译工具链和依赖。
Go 多阶段构建为什么能减小镜像体积
因为 Go 编译产物是静态二进制，不依赖系统 libc 或 runtime；多阶段构建让编译环境（含 go、GOPATH、源码、依赖包）和运行环境完全隔离，最终镜像只保留可执行文件本身。
常见错误现象：docker images 显示镜像动辄 800MB+，实际二进制才 10MB —— 那多半是直接用了 golang:alpine 或 golang:latest 做基础镜像且没分阶段。
- 编译阶段用
golang:1.22-alpine（带go和git，适合 CGO_ENABLED=0 场景） - 运行阶段必须用
scratch或alpine:latest（仅当启用 CGO 且依赖系统库时才选 alpine） - 若项目含 cgo 且调用
net包，默认 DNS 解析会失败 —— 需复制/etc/nsswitch.conf和/lib/libnss_files.so.*到 scratch 镜像，或改用alpine并安装ca-certificates
Dockerfile 中如何写正确的多阶段构建
核心是两个 FROM 指令 + COPY --from=0，不是靠注释或技巧“模拟”阶段。
典型错误：在单个 FROM golang 镜像里 go build 后删掉 $GOPATH —— 这根本没减少层数，缓存也难复用。
立即学习“go语言免费学习笔记（深入）”；
FROM golang:1.22-alpine AS builder WORKDIR /app COPY go.mod go.sum ./ RUN go mod download COPY . . RUN CGO_ENABLED=0 GOOS=linux go build -a -ldflags '-extldflags "-static"' -o /usr/local/bin/myapp . FROM scratch COPY --from=builder /usr/local/bin/myapp /myapp ENTRYPOINT ["/myapp"]
-
CGO_ENABLED=0是关键开关，关掉才能生成真正静态链接的二进制 -
-a强制重新编译所有依赖（避免缓存导致的隐式动态链接） -
-ldflags '-extldflags "-static"'是针对某些底层 C 依赖的兜底加固（如 sqlite、openssl 绑定） - 不要用
ADD替代COPY，ADD自动解压 tar 会意外引入额外文件
构建命令和本地验证要点
用 docker build 默认行为即可，无需额外参数 —— 多阶段是 Dockerfile 语法原生支持，不是插件功能。
容易被忽略的验证点：镜像是否真不含调试符号、是否误带源码或测试文件。
- 本地检查二进制：运行
file myapp应显示statically linked；ldd myapp应报not a dynamic executable - 检查镜像内容：
docker run --rm -it <image-id> ls -l /，只该有/myapp和可能的/etc/ssl/certs（如果用了 alpine） - 构建时加
--no-cache测试真实体积，避免因 layer 缓存掩盖问题 - CI 中若用 Kaniko 等无 Docker daemon 工具，确认其支持多阶段构建（v1.0+ 基本都支持）
什么时候不该用 scratch 镜像
不是所有 Go 程序都能直接扔进 scratch —— 关键看是否绕不开系统调用或外部配置。
典型场景：程序要读 /proc、调用 exec.LookPath、依赖 /etc/resolv.conf 或证书路径、用 os/user.Lookup*。
- 最轻量替代方案是
FROM alpine:latest，再apk add --no-cache ca-certificates - 若需调试，可在构建阶段保留
strace或busybox，但别放进最终镜像 - 用
upx压缩二进制？别。UPX 加壳后无法被 seccomp 或安全扫描工具识别，多数生产环境禁用 - 注意 Alpine 的 musl libc 和 glibc 行为差异（比如 time.Location 名称、信号默认处理），本地开发用 Ubuntu/macOS 编译时更易踩坑
真正省体积的关键不在选哪个最小 base 镜像，而在于编译阶段是否干净、运行阶段是否只 COPY 必需项 —— 多阶段只是手段，克制才是本质。
