Go原生支持多平台编译，但Makefile中必须每条命令前显式设置GOOS和GOARCH（如GOOS=linux GOARCH=amd64），否则仅构建当前系统平台；需禁用CGO_ENABLED=0、输出路径带平台标识、Windows加.exe后缀、ARM按需设GOARM，且须前置mkdir -p确保目录存在。
Go 原生支持多平台构建，但不显式设置 GOOS 和 GOARCH，就永远只生成当前系统平台的二进制——哪怕输出名写成 app-linux，在 macOS 上跑出来的仍是 darwin 格式。
GOOS 和 GOARCH 必须每条命令前显式设置
Makefile 或 shell 脚本里写 export GOOS=linux 然后跟 go build，第二行根本不会继承变量。Make 不是 shell，它把每行当独立命令执行。
- 错误写法：
export GOOS=linux换行go build -o bin/app-linux ./cmd/myapp - 正确写法：
GOOS=linux GOARCH=amd64 go build -o bin/app-linux-amd64 ./cmd/myapp - Windows 目标必须加
.exe后缀：GOOS=windows GOARCH=amd64 go build -o bin/app-windows-amd64.exe ./cmd/myapp（go build会自动补，但显式写更可控） - ARM 平台注意
GOARM：ARMv7 设备需加GOARM=7，否则运行时可能 panic
CGO_ENABLED=0 是跨平台稳定的默认选择
只要项目没硬依赖 C 库（比如 sqlite3、openssl、systemd），禁用 CGO 几乎总是更简单、更可靠。启用后不仅需要目标平台的 C 工具链，还容易在 Alpine 容器或 Windows 上直接失败。
- Linux 二进制在 Alpine 里报
not found？大概率是 libc 动态链接问题 → 加CGO_ENABLED=0 - macOS 编译 Windows 二进制时报
exec: "gcc": executable file not found？→ 加CGO_ENABLED=0 - 副作用：禁用后
net包用纯 Go DNS 解析器（不读/etc/resolv.conf），若必须用系统 DNS，启动时加GODEBUG=netdns=system
输出路径和文件名必须带平台标识
所有平台二进制塞进同一个 bin/app，反复 make 会覆盖，CI 发错包是高频事故。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 建议命名格式：
$(BIN_NAME)-$(GOOS)-$(GOARCH)，如myapp-linux-amd64、myapp-darwin-arm64 - Windows 单独处理后缀：
myapp-windows-amd64.exe，别指望系统自动补 - 前置创建目录：
mkdir -p bin/必须作为每个build-*target 的第一行，否则go build因路径不存在失败
验证交叉编译结果是否真的可用
编译不报错 ≠ 能在目标平台跑。最轻量的验证方式是看 file 输出：
-
file myapp-windows-amd64.exe应含PE32+ executable (console) x86-64 -
file myapp-linux-arm64应含ELF 64-bit LSB executable, ARM aarch64 - 别在宿主机上双击或
./myapp-windows-amd64.exe—— 这必然报exec format error，不是构建失败，是误操作 - 体积过大？加
-ldflags="-s -w"去掉调试符号和 DWARF 信息
最容易被忽略的是：每次构建都得重设 CGO_ENABLED、GOOS、GOARCH，它们不继承、不缓存、不跨行生效；还有 Windows 后缀和输出目录创建，这两个点一漏，整个发布流程就卡在交付环节。
