单阶段构建的Go镜像动辄800MB+，因golang:1.22等官方镜像基于Debian、本身超900MB，叠加源码、mod缓存及中间产物，最终仅几MB二进制有用；多阶段须显式命名builder阶段并用--from精准复制，禁用CGO、加-s -w静态编译，配合alpine或distroless基础镜像，再配全.dockerignore，方可压至10MB内。
为什么单阶段构建的Go镜像动辄800MB+
因为 golang:1.21 这类官方镜像本身基于 debian，体积就超900MB；再加上源码、go mod 缓存、构建中间产物，最终镜像里真正运行用的只有几MB的二进制文件，其余全是冗余。你跑 docker history 会看到大量层堆叠，其中大部分在生产环境毫无意义。
多阶段构建必须用 --from 显式复制产物
关键不是“用了多个 FROM”，而是控制哪些文件能进最终镜像。常见错误是漏写 --from=builder，或路径写错导致复制失败：
-
COPY --from=builder /app/myapp .—— 正确：指定来源阶段名和绝对路径 -
COPY --from=0 /app/myapp .—— 可用但不推荐：数字索引易随Dockerfile调整失效 -
COPY /app/myapp .—— 错误：这是从本地上下文复制，不是从前一阶段
另外注意：--from 阶段的 WORKDIR 和 COPY 路径必须匹配，否则 stat /app/myapp: no such file 会静默失败（构建不报错，但运行时报找不到命令）。
Go静态编译 + Alpine基础镜像是体积压缩双保险
Go默认动态链接 libc，直接扔进 alpine 会报 standard_init_linux.go:228: exec user process caused: no such file or directory。必须关掉 CGO：
RUN CGO_ENABLED=0 GOOS=linux go build -a -ldflags '-s -w' -o myapp main.go
说明：
-
CGO_ENABLED=0强制静态链接，避免依赖 glibc -
GOOS=linux确保交叉编译目标一致 -
-s -w去除符号表和调试信息，再省2–3MB - 运行阶段用
alpine:3.17（约5MB）比scratch更实用：自带sh、ca-certificates，方便调试和HTTPS调用
容易被忽略的体积陷阱：.dockerignore 和 RUN 指令合并
即使用了多阶段，如果 .dockerignore 没配好，COPY . . 仍会把 node_modules、vendor、.git 等无用目录带进 builder 阶段，拖慢构建速度并污染缓存。务必包含：
.git .gitignore README.md node_modules vendor *.md
另外，builder 阶段的 RUN 指令别拆太碎：
- ❌
RUN go mod download+RUN go build ...→ 多一层，且go.mod变更时整个层失效 - ✅
RUN go mod download && go build ...→ 合并后，只要go.mod不变，缓存可复用
最终镜像体积能否压到10MB以内，不只看阶段数，更取决于是否切断了所有非必要输入路径和中间产物残留。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
