核心是多阶段构建+cgo_enabled=0静态编译：第一阶段用golang镜像编译，第二阶段仅拷贝静态二进制到alpine或scratch镜像，并前置copy go.mod/go.sum、启用buildkit、设置goproxy和-ldflags="-s -w"确保缓存复用与安全精简。
容器内搭建 Golang 环境并实现自动化编译，核心不是“装 Go”，而是避免重复安装、跳过环境变量手动配置、直接复用官方镜像能力——golang 镜像本身已预装完整工具链，只需按需选择阶段和参数。
用 golang:latest 镜像但别直接 go build
很多人在 Dockerfile 里写 RUN go build -o app . 就完事，结果 CI 构建慢、镜像大、本地调试和 CI 行为不一致。问题出在没分阶段：构建阶段会把 $GOROOT、go.mod 缓存、编译器、测试工具全打包进最终镜像。
- 永远用多阶段构建，第一阶段用
golang:1.22（或锁定具体小版本，如golang:1.22.6），第二阶段用alpine:latest或scratch -
COPY go.mod go.sum ./必须放在COPY . .之前，否则 Docker 缓存失效，每次都会重下依赖 - 不要在构建阶段
RUN go test后再RUN go build—— 测试失败时构建仍继续，应加set -e或用go build && go test链式判断
CGO_ENABLED=0 在容器里不是可选项
容器默认启用 CGO，一旦代码或依赖里调用了 C 函数（比如 net 包在某些场景下、sqlite3、zlib），构建会失败或生成带动态链接的二进制文件，导致 scratch 镜像启动报 no such file or directory 错误。
- 所有面向生产环境的容器构建，必须显式设
CGO_ENABLED=0，哪怕你没写#import "C" - 设置位置：在
FROM golang:1.22 AS builder后立即ENV CGO_ENABLED=0，比在go build命令前加更安全 - 例外情况只有当你明确需要 cgo（如调用 OpenSSL 或系统库），此时第二阶段不能用
scratch，得切到debian:slim并apt install libc6
Makefile + docker build --build-arg 实现参数化编译
硬编码 GOOS=linux GOARCH=amd64 在 Dockerfile 里，意味着换平台就得改文件、提交、触发 CI。实际项目常需一键生成 Windows/macOS/Linux 多版本，靠构建参数更灵活。
- Dockerfile 中用
ARG TARGETOS TARGETARCH，然后ENV GOOS=$TARGETOS GOARCH=$TARGETARCH - Makefile 里写：
build-linux: docker build --build-arg TARGETOS=linux --build-arg TARGETARCH=amd64 -t myapp:linux . - CI 中可传入
TARGETOS=${{ matrix.os }}，配合 GitHub Actions 的 matrix 功能批量构建 - 注意：
GOARM（用于 arm）和GO386（用于 386）这类变量无法通过ARG传递，得在RUN行里显式写死
本地开发容器与 CI 容器行为对齐的关键点
本地 docker build 成功，CI 却失败，90% 是因为忽略了构建上下文路径、用户权限、或 GOPROXY 差异。
-
docker build -f Dockerfile .的.必须是包含go.mod的根目录，否则go mod download找不到模块声明 - CI 默认以 root 运行容器，而本地开发可能用非 root 用户；若项目用了
os.UserHomeDir()或写临时文件，需统一用USER 1001或挂载/tmp - 国内 CI 环境务必设
ENV GOPROXY=https://goproxy.cn,direct，否则go mod download超时失败 -
go build -ldflags="-s -w"应始终开启：去掉符号表和调试信息，既减体积又防逆向，无副作用
真正省时间的不是“快速搭建”，而是让每次 docker build 都复用上一次的模块下载和编译中间产物；最容易被忽略的是 CGO_ENABLED 和 GOPROXY 这两个环境变量——它们不报错，但会让构建结果在目标环境静默崩溃。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
