跨平台编译需设GOOS/GOARCH并强制CGO_ENABLED=0：GOOS支持linux/windows/darwin，GOARCH支持amd64/arm64/386；启用cgo会导致动态链接glibc，Alpine下必崩，必须静态编译并通过docker run alpine验证。
直接在本地机器上就能编译出 Linux、Windows 或 macOS 的可执行文件，不需要切换系统、装虚拟机，也不依赖目标平台的 Go 环境——前提是正确设置 GOOS 和 GOARCH，并且处理好 cgo 带来的动态链接风险。
GOOS/GOARCH 是跨平台编译的核心开关
Go 原生支持交叉编译，靠的就是这两个环境变量。它们不改变源码，只告诉编译器“你想让这个二进制跑在哪”。
-
GOOS控制目标操作系统：linux、windows、darwin（不是macos） -
GOARCH控制 CPU 架构：amd64、arm64、386（注意：32 位 Windows 要用386，不是i386） - 组合示例：
GOOS=linux GOARCH=arm64 go build -o app-linux-arm64 main.go→ 生成适配树莓派或 AWS Graviton 的 Linux 二进制 - 错误写法：
GOOS=macos会失败，必须用darwin；GOARCH=arm在新版本中已被弃用，ARM64 必须写arm64
CGO_ENABLED=0 不是可选项，是上线前必加的安全项
只要代码里用了标准库的 net、os/user、os/signal 等模块，底层就可能触发 cgo。默认开启时，跨平台编译会尝试调用目标系统的 C 工具链（比如 Linux 的 gcc），而你本地根本没有——直接报错：cross compilation with cgo enabled requires a cgo-enabled compiler for the target。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 加
CGO_ENABLED=0后，Go 会退回到纯 Go 实现：DNS 解析走内置逻辑，用户查找失效（user.Lookup返回user: lookup userid 0: no such user），但二进制彻底静态链接 - 验证是否生效：
file app-linux-amd64输出里必须含statically linked；ldd app-linux-amd64应提示not a dynamic executable - 常见坑：
CGO_ENABLED=0必须放在命令最前面，写成go build CGO_ENABLED=0 ...无效；Docker 构建时也要显式传入，不能只靠宿主机环境变量
Alpine 容器是检验跨平台二进制最严苛的试金石
很多团队在 Ubuntu/CentOS 上测试成功，一上生产（尤其是 Kubernetes + Alpine 镜像）就崩，报错 No such file or directory。这不是路径错了，而是二进制试图加载 glibc 动态解释器，而 Alpine 用的是 musl libc。
立即学习“go语言免费学习笔记（深入）”；
- 真正有效的验证命令：
docker run --rm -v $(pwd):/work -w /work alpine:latest ./app-linux-amd64 - 如果失败，90% 是漏了
CGO_ENABLED=0，或者构建时没清掉缓存（加-a参数强制重编所有依赖：CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -a -o app main.go） - 别信
file命令输出的 “ELF 64-bit LSB executable” —— 它只说明格式对，不保证无依赖；strace ./app在 Alpine 里跑，看到execve("/lib64/ld-linux-x86-64.so.2", ...)就说明还在找 glibc
跨平台编译最难的部分从来不是“怎么生成文件”，而是“生成的文件有没有藏起来的 libc 依赖”。每次改 GOOS 或 GOARCH，都得重新跑一遍 CGO_ENABLED=0，再进 Alpine 容器实测一次——省掉这步，上线后大概率要半夜爬起来修。
