go项目必须用--from多阶段构建，因其静态编译特性可将700mb单阶段镜像压缩至15mb，仅保留静态二进制与必要运行时依赖，同时规避源码、编译器、cgo兼容性及环境变量泄露等安全与运行风险。
Go 语言用 Docker 多阶段构建，不是“学完再用”，而是从第一个 Dockerfile 就该用——因为 Go 的静态编译特性与多阶段构建天然匹配，不这么写，镜像体积和安全风险会立刻暴露。
为什么 Go 项目必须用 --from 而不是单阶段构建
单阶段构建把 golang:1.23-alpine 整个镜像层都打进最终产物里：包括 Go 编译器、go.mod、源码、测试文件、缓存目录。一个 Hello World 级的 Web 服务，镜像轻松突破 700MB；而生产环境只需要一个几 MB 的静态二进制文件 + ca-certificates。
-
golang:1.23-alpine镜像本身约 85MB，但运行go build后叠加的中间层会让最终镜像膨胀数倍 - 单阶段镜像中残留的
/app/go.sum或/root/.cache/go-build可能泄露依赖版本或内部路径 - Kubernetes 拉取 700MB 镜像比拉取 15MB 多花 5–10 秒，滚动更新时延迟明显
COPY --from=builder 的路径必须绝对且精确
很多人复制失败，不是语法错，而是路径没对齐工作目录（WORKDIR）和 COPY 源路径。第一阶段的 WORKDIR /app 和第二阶段的 WORKDIR /root/ 是独立的，不能假设“相对路径自动继承”。
- 第一阶段编译命令是
go build -o /app/server，那第二阶段就得写COPY --from=builder /app/server . - 如果第一阶段用了
WORKDIR /src但COPY到了/src/main.go，那二进制默认输出在/src/server，不是/app/server - Alpine 镜像里没有
ls，调试时可在第二阶段临时加RUN ls -l /app/确认文件是否存在（上线前删掉）
静态编译参数 CGO_ENABLED=0 GOOS=linux 必须放在构建阶段
这个组合不是可选优化，而是 Alpine 运行阶段能跑起来的前提。Alpine 使用 musl libc，而默认 go build 生成的是 glibc 链接的动态二进制，直接运行会报 standard_init_linux.go:228: exec user process caused: no such file or directory —— 实际是找不到 libc.so.6。
-
CGO_ENABLED=0强制禁用 CGO，所有依赖打包进二进制，不依赖系统 C 库 -
GOOS=linux确保目标平台为 Linux（即使你在 macOS 上构建也必须设） - 漏掉任一参数，
COPY --from=builder过来的文件在 Alpine 里根本exec不起来
阶段命名（AS builder）不是装饰，而是引用前提
--from 后面跟的必须是显式命名的阶段名，不能是镜像标签或隐式序号。Docker 不支持 --from=0 或 --from=golang:1.23-alpine 这类写法。
- 第一阶段必须写
FROM golang:1.23-alpine AS builder，第二阶段才能用COPY --from=builder - 如果写了两个
AS builder，Docker 会报错：duplicate stage name “builder” - 阶段名区分大小写，
--from=Builder和AS builder不匹配
最容易被忽略的一点：多阶段构建的“阶段”之间完全隔离，连环境变量都不继承。别指望在 builder 阶段 ENV GOPROXY=https://goproxy.cn 后，runtime 阶段还能用上这个代理——它只影响 builder 内部的 go mod download。真正要控制运行时行为（比如日志级别、监听地址），得靠启动命令传参或挂载配置文件，而不是依赖构建阶段的环境设置。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
