交叉编译成功的关键是正确设置GOOS、GOARCH和CGO_ENABLED：三者必须同时显式配置，缺一或错一即导致exec format error或panic；GOOS与GOARCH需配对且值准确（如darwin不支持386，arm64非aarch64），CGO_ENABLED=0可避免动态库依赖问题，但含import "C"时必须配目标平台C工具链。
交叉编译不是“能不能”，而是GOOS、GOARCH和CGO_ENABLED三个变量是否设对、关对、用对。设错一个，生成的二进制大概率在目标机器上直接报cannot execute binary file: Exec format error或运行时panic。
GOOS 和 GOARCH 必须同时显式设置，缺一不可
只设GOOS=linux不设GOARCH，Go 会沿用你本机的架构（比如 macOS M2 是arm64），结果得到linux/arm64——但你要部署的是 Intel 服务器？那就跑不起来。
-
GOOS常见值：linux、windows、darwin、freebsd；darwin不支持386，只认amd64和arm64 -
GOARCH常见值：amd64、arm64、386（注意不是aarch64） - Windows 下输出文件名必须带
.exe后缀才可双击执行，go build -o app.exe比-o app更稳妥 - 推荐用
env GOOS=xxx GOARCH=yyy go build ...方式临时赋值，避免export污染当前 shell 环境
CGO_ENABLED=0 是稳定生成静态二进制的关键开关
默认开启 CGO 时，Go 会尝试链接宿主机的 C 库（如 macOS 的libSystem、Linux 的glibc）。你在 Mac 上编译linux/amd64，链接器根本找不到ld-linux-x86-64.so.2，要么构建失败，要么生成的程序在目标机上因动态库缺失而崩溃。
- 95% 的纯 Go 项目应强制加
CGO_ENABLED=0：例如CGO_ENABLED=0 GOOS=linux GOARCH=arm64 go build -o myapp - 关 CGO 后，
net包 DNS 解析自动 fallback 到 Go 原生实现（读/etc/resolv.conf），行为一致但路径来源变了 -
os/user.Current()可能返回nil或 panic —— 这是纯 Go 实现的限制，不是 bug - 若代码或依赖里有
import "C"（哪怕只是空导入），CGO_ENABLED=0会直接报错：cannot use cgo when CGO_ENABLED=0
如何快速检查是否真能跨平台运行
别信文件名，也别只看file输出。真正验证要分两步：
- 用
file myapp确认格式：比如输出ELF 64-bit LSB executable, x86-64对应linux/amd64，Mach-O 64-bit executable arm64对应darwin/arm64 - 用
ldd myapp（Linux）或otool -L myapp（macOS）检查动态链接：如果输出not a dynamic executable，说明是静态链接，可放心分发 - Windows 上无法用
ldd，但可用dumpbin /dependents myapp.exe（需 VS 工具链）查看依赖项 - 本地无法直接运行交叉产物：Mac 上生成的
linux/amd64二进制，./myapp必然报Bad CPU type in executable——这正常，不是编译失败
最容易被忽略的一点：只要源码或任意依赖中存在import "C"，哪怕没写任何 C 代码，整个构建就脱离了“纯 Go 交叉编译”范畴。这时候CGO_ENABLED=0会失败，而CGO_ENABLED=1又要求你配齐目标平台的 C 工具链（比如aarch64-linux-gnu-gcc），工程成本陡增。遇到这种情况，优先考虑替换依赖（如用github.com/ncruces/go-sqlite3代替mattn/go-sqlite3），而不是硬上 cgo。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
