Docker构建Go镜像体积大的根本原因是未使用多阶段构建分离编译与运行环境；应通过FROM...AS builder命名构建阶段，builder中用CGO_ENABLED=0静态编译，最终阶段选用scratch或alpine并仅COPY二进制。
用 docker build 构建 Go 应用镜像时为什么体积大？
直接 go build 生成的二进制在基础镜像里跑，但若用 golang:alpine 或 golang:latest 作为构建环境，编译产物会静态链接 libc（尤其在非 alpine 上），且镜像自带 Go 工具链、源码、模块缓存，最终镜像常超 1GB。根本原因是没分离构建阶段和运行阶段。
多阶段构建中如何正确使用 FROM ... AS builder？
必须显式命名构建阶段，否则 COPY --from=0 这类引用会失效；同时要确保最终阶段不带任何 Go 相关依赖——只放编译好的二进制和必要配置文件。
-
builder阶段用golang:1.22-alpine（小体积、musl 兼容）或golang:1.22-slim（glibc，兼容性更广） - 最终阶段优先选
scratch（零依赖纯二进制）或alpine:latest（需ca-certificates等时） - 务必在
builder阶段执行CGO_ENABLED=0 go build -a -ldflags '-s -w'：禁用 cgo 避免动态链接，-s -w去除调试信息和符号表
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 '-s -w' -o myapp . FROM scratch COPY --from=builder /app/myapp /myapp CMD ["/myapp"]
CGO_ENABLED=0 在哪些场景下不能用？
当你的 Go 代码调用了 cgo 特性（比如 net 包在某些 DNS 场景下、os/user、os/signal 的部分实现、或显式 import "C"），禁用后会编译失败或运行时 panic。此时不能硬切 scratch，得保留基础系统库。
- 检查是否含
import "C"或依赖含 cgo 的第三方包（如github.com/mattn/go-sqlite3） - 若必须用 cgo，改用
gcr.io/distroless/static-debian12或alpine:latest，并安装对应运行时依赖（如apk add ca-certificates） - 交叉编译时设
GOOS=linux GOARCH=amd64，避免本地平台干扰
如何验证镜像是否真“最小”且无冗余层？
别只看 docker images 总大小——同一镜像不同 tag 可能共享层；真正要查的是运行时实际加载内容和攻击面。
- 用
docker history看每层命令和大小，确认没有残留go mod download、go build中间产物 - 运行容器后执行
docker exec -it，确认只有ls -la / /myapp和必要文件（/etc/ssl/certs等仅在非 scratch 时存在） - 扫描安全风险：
trivy image检查 OS 包漏洞，docker scan辅助验证
最易被忽略的是：没清理构建缓存导致 go mod download 层被意外保留，或忘记 COPY --from=builder 后删掉中间临时文件。哪怕只多一个 go.sum 文件拷进最终镜像，都可能让 scratch 镜像启动失败。
