go build 默认产物在 docker 中体积膨胀主因是 cgo 启用导致动态链接 libc；禁用 cgo（cgo_enabled=0）可生成纯静态二进制，适配 scratch 或 alpine 镜像，但需注意 dns 解析行为变化及运行时依赖验证。
为什么 go build 默认产物在 Docker 里会胖三倍？
因为 go build 默认生成的是静态链接可执行文件，但启用了 CGO（比如用到了 net 包的 DNS 解析），就会动态链接系统 libc；Docker 基础镜像（如 alpine）没装 glibc，你又切回 debian:slim，结果镜像直接涨到 120MB+——不是代码大，是带了一整套运行时。
- 用
CGO_ENABLED=0 go build强制纯静态编译，生成的二进制不依赖系统 libc，才能安全塞进scratch或alpine - 但注意：禁用 CGO 后，
net.Resolver会 fallback 到纯 Go DNS 解析（不走 /etc/resolv.conf 的 nameserver），某些内网环境可能解析失败 - 验证是否真静态：本地跑
ldd your-binary，输出 “not a dynamic executable” 才算过关
多阶段构建里 COPY 什么、不 COPY 什么？
常见错误是把整个 go mod download 缓存或 vendor/ 目录 COPY 进最终镜像，或者在 builder 阶段反复 go mod download 导致 layer 失效。
- 只 COPY 最终二进制：
COPY --from=builder /app/myserver /myserver，别碰src/、go.mod、go.sum - builder 阶段 WORKDIR 设为
/app，且go build -o /app/myserver .，确保路径固定，避免 COPY 时路径错位 - 如果用了
vendor/，只在 builder 阶段COPY vendor/ vendor/，且必须紧挨着go mod vendor后执行，否则缓存失效
alpine vs scratch：选哪个取决于 runtime 依赖
scratch 镜像只有 0B，但连 sh 都没有，docker exec -it 进不去，日志重定向、信号转发（如 SIGTERM）也容易出问题；alpine 有 busybox，体积才 5MB，够用又可控。
- 纯静态二进制 + 不需要 shell 调试 → 用
FROM scratch，但得手动加ENTRYPOINT ["/myserver"]，不能写CMD（会被 shell 包一层） - 想
docker exec -it container sh查问题，或程序内部 exec 其他命令 → 必须用alpine，且建议显式安装ca-certificates（HTTPS 请求需要） - 别用
golang:alpine直接跑服务！它是 builder 镜像，含大量 dev 工具和未清理的包缓存，体积超 400MB
ENV 和构建参数怎么传才不泄露、不 bloated？
很多人把 GOOS/GOARCH 写死在 Dockerfile 里，或者用 ARG 传敏感配置（比如 API key），结果 build cache 暴露在镜像历史里。
立即学习“go语言免费学习笔记（深入）”；
- 跨平台构建用
docker build --platform linux/amd64，Dockerfile 里别硬编码GOOS；Go 1.21+ 默认支持多平台交叉编译 -
ARG只用于构建时开关（如BUILD_ENV=prod），敏感值必须通过--secret或挂载文件传入，绝不在 ENV 中设密码或 token - 最终镜像里删掉所有构建残留：用
RUN apk del .build-deps（alpine）或RUN apt-get clean && rm -rf /var/lib/apt/lists/*（debian）
最常被跳过的一步：没验证最终镜像里真的只剩一个二进制。用 docker run --rm -it image-name ls -la / 看一眼，如果出现 etc/、usr/、lib/，说明 base 镜像或 COPY 范围错了。
