为什么 Go 的 Docker 多阶段构建容易留一堆没用的依赖？
因为默认 go build 会把 CGO_ENABLED=1 下的系统库（比如 libc、libpthread）静态链接进二进制，但构建镜像时若没关 CGO，又用了带 glibc 的基础镜像（如 golang:1.22），最终产物就悄悄带上了动态依赖——哪怕你后续 COPY 到 alpine 或 scratch，运行时仍可能报 no such file or directory，实际是动态链接失败。
- 务必在构建阶段显式设置
CGO_ENABLED=0，让 Go 编译出纯静态二进制 - 避免用
golang:xxx镜像做最终运行环境，它体积大、有 shell、含调试工具，和 Go 二进制“零依赖”特性冲突 - 如果项目真要调 C（比如用
cgo调sqlite3），就得保留CGO_ENABLED=1，但必须用匹配的libc环境（比如gcr.io/distroless/cc或alpine:latest），不能硬塞进scratch
怎么写一个真正精简的 Go 多阶段 Dockerfile？
核心就两步：第一阶段只编译，第二阶段只运行。中间不 COPY 源码、不装 git、不保留 go.mod 或测试文件。
- 构建阶段用
golang:1.22-alpine或官方golang:1.22-slim，别用latest—— tag 不固定会导致 CI 构建结果不可复现 - 编译命令写成
CGO_ENABLED=0 GOOS=linux go build -a -ldflags '-s -w' -o /app/main .：-a强制重新编译所有依赖，-s -w去掉符号表和调试信息，能减掉 30%~50% 体积 - 运行阶段直接用
scratch，COPY 二进制前先chown root:root，否则非 root 用户启动可能因权限被拒
FROM golang:1.22-slim AS builder WORKDIR /app COPY go.mod go.sum ./ RUN go mod download COPY . . RUN CGO_ENABLED=0 GOOS=linux go build -a -ldflags '-s -w' -o /app/main . FROM scratch COPY --from=builder /app/main /app/main ENTRYPOINT ["/app/main"]
什么时候不该用 scratch？常见报错怎么快速定位？
不是所有 Go 程序都能直接扔进 scratch。最典型的是用了 net.LookupHost 或 http.DefaultClient 后 DNS 解析失败，错误是 lookup example.com: no such host —— 这不是代码 bug，是 scratch 里缺 /etc/resolv.conf 和 /etc/nsswitch.conf。
- 遇到 DNS 问题，先试
FROM alpine:3.19替代scratch，它小（~5MB）、有基础 libc 和 DNS 配置，兼容性远好于scratch - 如果程序读了
/proc（比如查 CPU 数量）、或依赖/dev/urandom，scratch默认不挂载这些路径，得靠 Docker run 时加--tmpfs /tmp --tmpfs /run或显式VOLUME - 用
docker run --rm -it <image> ls -l /etc</image>快速确认容器内有没有必要配置文件
Go module 依赖太多导致构建慢？缓存策略怎么设才有效？
Docker 构建缓存失效往往是因为 COPY . . 放太早，一改 README 就重跑 go mod download。关键不是“怎么加速”，而是“哪步该缓存、哪步不该”。
立即学习“go语言免费学习笔记（深入）”；
-
COPY go.mod go.sum ./必须在COPY . .之前，且单独成层，这样依赖没变时，go mod download就能命中缓存 - 不要在构建阶段执行
go test，除非 CI 明确需要；它不贡献最终镜像，却拖慢构建、干扰缓存 - 如果用了私有模块（
replace或GOPRIVATE），记得在 builder 阶段COPY对应的认证文件（如~/.netrc），否则缓存会卡在go mod download
go 命令，scratch 里也不该默认有 DNS。这些不是配置问题，是执行假设的错位。 
