docker镜像过大因from golang:1.22含完整开发环境；应采用多阶段构建，第一阶段用golang:1.22-alpine编译，第二阶段用scratch或alpine仅复制静态二进制，并加cgo_enabled=0和-ldflags="-s -w"优化。
为什么 Dockerfile 里用 FROM golang:1.22 直接编译再运行，镜像会大到 900MB+
因为官方 golang 镜像自带完整编译工具链、/usr/src、pkg、调试符号，甚至 apt 包管理器——你只想要一个二进制文件，它却塞给你整个开发环境。
典型错误是写成这样：
FROM golang:1.22 WORKDIR /app COPY . . RUN go build -o server . CMD ["./server"]
结果镜像含 GCC、Git、C header、Go src 等冗余内容，且基础层无法复用。
- 真正需要的只是 Go 编译器 + 你的代码 → 编译出静态链接的二进制
- 运行时完全不需要 Go 环境，
alpine:latest或scratch就够了 - 多阶段构建第一阶段负责编译，第二阶段只拷二进制，不带任何源码或依赖
go build -ldflags 关键参数：去掉调试信息、强制静态链接
默认 go build 生成的二进制仍可能动态链接 libc（尤其在 Alpine 上跑会报 no such file or directory），且带 DWARF 调试符号，徒增体积。
立即学习“go语言免费学习笔记（深入）”；
必须加这两项：
-
-ldflags="-s -w"：去掉符号表和调试信息，通常省 3–5MB -
-ldflags="-extldflags '-static'"（Linux 下）或直接设CGO_ENABLED=0：禁用 cgo，确保纯静态链接 - 如果用了
net/http以外还调os/user或netDNS 解析，CGO_ENABLED=0更稳妥，否则 Alpine 镜像里缺libc会 panic
推荐构建命令：
CGO_ENABLED=0 go build -ldflags="-s -w" -o server .
用 scratch 还是 alpine 当最终运行镜像？看日志和调试需求
scratch 是空镜像，0 字节基础层，最瘦；但没 sh、没 ls、没 strace，容器启动失败时连 exec -it 都进不去。
alpine:latest 只有 ~5MB，带 sh 和 apk，适合保留基本诊断能力。
- 生产环境首选
scratch，前提是你的程序已充分测试、日志完备、不依赖外部命令 - 预发/CI 环境建议用
alpine，方便docker exec -it CONTAINER sh查/proc或临时抓包 - 别用
debian或ubuntu做运行镜像——哪怕只装curl，也会引入几百 MB 无关包
多阶段构建中容易漏掉的三个硬伤
很多人写了两阶段，镜像还是胖，问题往往不在编译，而在“搬运”环节。
- 忘记
COPY --from=builder的路径写错，比如把/app/server写成./server，导致复制的是宿主机文件（可能未更新） - 没清理中间产物：
go mod download缓存在 builder 阶段残留，虽不影响最终镜像，但拉取 builder 镜像时多传几十 MB - 误把
go.mod和go.sumCOPY 到 final 阶段——它们对运行零价值，且可能暴露依赖版本
正确写法示例（精简版）：
FROM golang:1.22-alpine AS builder WORKDIR /app COPY go.mod go.sum ./ RUN go mod download COPY . . RUN CGO_ENABLED=0 go build -ldflags="-s -w" -o server . FROM scratch COPY --from=builder /app/server / CMD ["/server"]Golang 二进制本身足够干净，但 Docker 构建过程中的路径、环境变量、阶段间传递，才是实际压垮镜像大小的隐形推手。多看一眼
docker history 输出，比背十遍参数管用。 
