GOOS和GOARCH必须显式设置才能交叉编译；CGO_ENABLED=0是关键开关，否则依赖C库会导致链接失败；含import "C"的代码需配对应C工具链或替换为纯Go实现。
GOOS 和 GOARCH 环境变量必须显式设置
Go 交叉编译不依赖外部工具链，靠的是 GOOS 和 GOARCH 这两个环境变量控制目标平台。不设它们，默认就编译当前系统能跑的二进制——也就是“没交叉”。
- 常见组合：
GOOS=linux GOARCH=arm64编译 Linux ARM64 可执行文件；GOOS=windows GOARCH=amd64编译 Windows 64 位 exe -
GOOS可选值包括linux、windows、darwin、freebsd等；GOARCH常见有amd64、arm64、386、arm - 运行
go env -w GOOS=xxx GOARCH=yyy是全局设置，容易污染后续开发；更安全的做法是单次命令前临时赋值：GOOS=linux GOARCH=arm64 go build -o myapp . - 注意：
darwin（macOS）只支持amd64和arm64，不支持386；windows下生成的可执行文件后缀自动为.exe，无需手动加
CGO_ENABLED=0 是跨平台编译稳定性的关键开关
默认开启 CGO，意味着 Go 会尝试调用系统 C 库（比如 glibc）。但你在 macOS 上编译 Linux 二进制时，本地没有 glibc，链接就会失败，或者生成的程序在目标机器上因库版本不匹配而 panic。
- 纯 Go 程序（没 import
"C"、没用 cgo 相关特性）可以且应该关闭：CGO_ENABLED=0 GOOS=linux GOARCH=arm64 go build -o myapp . - 如果代码里用了
net包的 DNS 解析（默认走 cgo），关闭 CGO 后会 fallback 到 Go 自己的解析器（基于 /etc/resolv.conf），行为一致但配置来源变了 - 若必须用 cgo（比如调用 OpenSSL 或 sqlite3），就得配好对应平台的交叉 C 工具链（如
aarch64-linux-gnu-gcc），并设置CC_aarch64_linux_gnu等环境变量——这已脱离 Go 原生能力，容易卡住
import "C" 会导致交叉编译失败，除非你彻底控制 C 构建环境
只要源码中出现空 import "C"（哪怕没写任何 cgo 注释），Go 就会启用 cgo 模式。此时 CGO_ENABLED=0 会让构建直接报错：gcc: command not found 或 cannot use cgo when CGO_ENABLED=0。
- 检查所有
.go文件，搜索import "C"—— 它可能藏在第三方包里（比如某些旧版os/exec补丁、或数据库驱动） - 用
go list -f '{{.CgoFiles}}' ./...可快速发现哪些包含 cgo 文件 - 想绕过？不行。要么删掉 cgo 依赖，要么接受配 C 工具链的复杂度。别信“加个 -ldflags 就能解决”的说法——链接阶段照样崩
- 一个典型坑：用
github.com/mattn/go-sqlite3默认启 cgo；换成github.com/ziutek/mymysql或纯 Go 的github.com/glebarez/sqlite才能安全关 CGO
交叉编译出的二进制，依赖的 Go 运行时版本和目标机器无关
Go 编译出来的是静态链接二进制，自带运行时和垃圾收集器。它不依赖目标机器装了什么 Go 版本，也不需要安装 Go 环境就能跑。
立即学习“go语言免费学习笔记（深入）”；
- 但要注意：不同 Go 版本的 runtime 行为有细微差异（比如调度器策略、panic 栈格式），所以建议构建环境和 CI 中的 Go 版本尽量与线上部署版本对齐
- 用
go version myapp可查看该二进制由哪个 Go 版本构建；用file myapp能确认是否为静态链接（输出含statically linked） - 如果程序读取
os.Args[0]或调用exec.LookPath，注意路径分隔符（\vs/）和大小写敏感性（Windows vs Linux/macOS）——这些是逻辑兼容问题，不是编译问题
真正卡住人的往往不是 GOOS/GOARCH 记不住，而是某个深层依赖悄悄带了 cgo，或者 DNS 解析在关 CGO 后连不上内网服务——得去翻日志里那一行真实的错误，而不是盯着 “build failed” 干猜。
