应避免使用 golang:latest 镜像直接编译，因其缺失 git、curl、make 等工具，易导致 exec: "git": executable file not found 或 gcc: command not found 错误；推荐优先选用 golang:alpine（需手动安装 git 和 build-base）或 golang:slim（apt 安装 git），并显式设置 env goos=linux goarch=amd64 实现可靠交叉编译，同时务必设 cgo_enabled=0 保证静态链接，且在 dockerfile 中通过 go env -w 配置 goproxy 防止模块下载失败。
为什么不用 golang:latest 镜像直接编译？
因为官方镜像默认不含 git、curl、make 等基础工具，很多 Go 项目（尤其带 go:generate 或依赖 CGO_ENABLED=1 的包）一运行就报 exec: "git": executable file not found in $PATH 或 gcc: command not found。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 优先选
golang:alpine镜像，体积小但需手动装git和build-base（含 gcc） - 若项目用 cgo 或需调试，改用
golang:slim，再apt-get update && apt-get install -y git - 避免用
golang:latest—— 它实际指向最新稳定版，但 CI/CD 中易因版本漂移导致编译失败
Dockerfile 里怎么设 GOOS 和 GOARCH 才不踩坑？
本地开发机是 macOS ARM64，但目标部署环境是 Linux AMD64，不显式指定会导致编译出错二进制或 panic： exec format error。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 交叉编译必须在
docker build阶段设环境变量：ENV GOOS=linux GOARCH=amd64 - 若要多平台构建（如同时支持 linux/arm64），别靠
GOOS切换，改用docker buildx build --platform linux/amd64,linux/arm64 -
CGO_ENABLED=0要写在编译命令前，不是只写在 ENV 里；否则go build仍可能调用系统 libc
如何让容器内 go mod download 不卡住或拉错代理？
国内直连 proxy.golang.org 常超时，而镜像源配置错位置（比如只写在宿主机 ~/.bashrc）对容器无效。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 在
Dockerfile的FROM后立即 RUN：go env -w GOPROXY=https://goproxy.cn,direct - 若项目私有模块走公司 Nexus，追加
go env -w GONOPROXY=git.internal.company.com/* - 禁止在
go build命令里临时加-mod=vendor来绕过下载 —— 这会让容器无法感知go.mod更新，CI 构建结果不可信
容器里 go run main.go 能跑，但 go build 出的二进制在宿主机执行失败？
这是最隐蔽的坑：容器内默认用 CGO_ENABLED=1，生成的二进制动态链接宿主机没有的库（比如 libc 版本不匹配），报 no such file or directory 实际是找不到 so 文件。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 生产镜像务必关 cgo：
CGO_ENABLED=0 go build -o app . - 如果必须开 cgo（如调用 SQLite 或 OpenSSL），那就别把二进制拷出容器执行 —— 改用多阶段构建，最后阶段只放静态二进制 + 必要 so
- 验证是否真静态：在宿主机上
ldd ./app，输出not a dynamic executable才算过关
真正麻烦的从来不是“能不能编译”，而是“编译出来的能不能在目标环境跑”。环境变量、cgo、代理、平台架构——四个点只要漏一个，就会在部署那一刻才暴露。
