GOOS和GOARCH必须显式成对设置，否则默认继承宿主机环境变量（如macOS下GOOS=darwin），导致跨平台构建失败；CGO_ENABLED=0是静态链接前提，否则依赖libc无法在Alpine等最小化镜像中运行。
GOOS/GOARCH 必须显式设置，否则默认继承宿主机环境
在 macOS 上用 Docker 运行 golang 镜像构建 Linux 二进制时，file myapp 却显示 Mach-O 64-bit executable——这不是 Docker 的问题，而是 Go 编译器根本没“猜”目标平台，它只看环境变量。只要没设 GOOS 和 GOARCH，就会沿用当前 shell 的值（比如 macOS 下默认是 GOOS=darwin）。这会导致跨平台构建完全失效。
解决办法很简单：所有构建命令开头必须带明确声明：
GOOS=linux GOARCH=amd64 go build -o myapp .GOOS=windows GOARCH=arm64 go build -o myapp.exe .- 在 CI 脚本或 Makefile 中，避免裸写
go build，一律前置变量
CGO_ENABLED=0 是静态链接的前提，不是可选项
即使设置了 GOOS=linux，如果 CGO_ENABLED=1（Go 默认值），生成的仍是动态链接 ELF 文件，依赖 libc.so。这类二进制无法在 alpine、busybox 等最小化镜像中运行，docker run 会直接报 No such file or directory。
正确做法是强制禁用 cgo，并确保标准库也静态编译：
- 加
CGO_ENABLED=0—— 关键，必须显式写，不能省略 - 加
-a参数 —— 强制重编所有依赖（含标准库），防止残留 cgo 引用 -
-ldflags '-extldflags "-static"'—— 辅助加固，新版 Go 中虽非必需，但保留更稳妥
完整命令示例：CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -a -ldflags '-extldflags "-static"' -o myapp .
Windows 构建需注意 .exe 后缀和 GUI 标志
在非 Windows 系统（如 macOS/Linux）上交叉编译 Windows 程序时，go build 不会自动加 .exe 后缀，也不会处理图标或版本信息。若直接双击生成的文件，Windows 会提示“不是有效的 Win32 应用程序”——其实是后缀缺失或缺少 PE 头标志。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
关键操作有两层：
- 输出名必须显式指定
.exe：GOOS=windows GOARCH=amd64 go build -o app.exe . - 若要隐藏控制台窗口（GUI 程序），需加
-ldflags "-H windowsgui" - 若要嵌入图标或版本信息，得先用
winres或goversioninfo生成.syso文件，再参与构建
Docker 多阶段构建中容易漏掉环境隔离
很多人在 Dockerfile 里写 FROM golang:1.23 AS builder，然后直接 RUN go build，却没意识到：如果构建阶段没覆盖 GOOS，它仍可能从构建机继承错误值（尤其在 macOS 上用 Docker Desktop 构建时）。更糟的是，有人用 VOLUME 或 docker run -v 把宿主机代码挂进容器再构建，等于把本地环境变量全带进去了。
安全做法是切断所有隐式继承：
- 构建阶段命令全部用完整前缀：
CGO_ENABLED=0 GOOS=linux GOARCH=arm64 go build -o /app/myapp . - 运行阶段用
FROM scratch或FROM busybox，只COPY --from=builder /app/myapp /myapp - 禁止在构建阶段执行
source ~/.zshrc类命令，避免污染环境变量
真正可控的跨平台构建，从来不是“让工具自动适配”，而是每一步都亲手锁死目标平台、链接模式和输出格式。最容易被忽略的，就是以为设了 GOOS 就万事大吉，却忘了 CGO_ENABLED 这个开关一关一开，决定的是能不能扔进容器里跑。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
