Go交叉编译核心是显式设置GOOS和GOARCH并关闭CGO_ENABLED=0；漏设任一变量或未关CGO易致构建失败或动态链接错误，含import "C"需配对应C工具链。
Go 交叉编译不是“额外装个工具链”就能搞定的事，它靠的是 GOOS 和 GOARCH 两个环境变量驱动，且绝大多数情况下必须配合 CGO_ENABLED=0 才能稳定产出可部署的二进制。
GOOS 和 GOARCH 必须同时显式设置，缺一不可
只设 GOOS=linux 而不设 GOARCH，Go 会沿用当前宿主机的架构（比如你的 macOS 是 arm64），结果还是生成 darwin/arm64 二进制——根本没交叉。常见组合直接记牢：
-
GOOS=linux GOARCH=amd64→ Linux x86_64 -
GOOS=windows GOARCH=arm64→ Windows ARM64（后缀自动为.exe） -
GOOS=darwin GOARCH=arm64→ macOS Apple Silicon -
GOOS=linux GOARCH=arm64→ 嵌入式/树莓派等 ARM64 设备
别用 go env -w 全局设置，容易污染后续构建；推荐单次命令前临时赋值：env GOOS=linux GOARCH=arm64 go build -o app .
CGO_ENABLED=0 是默认安全选项，不是可选开关
只要代码里没 import "C"、没调用 OpenSSL/sqlite3 等 C 依赖，就该关掉 CGO。否则在 macOS 上编译 Linux 二进制时，go build 会试图链接本地的 libc，直接报错 exec: "gcc": executable file not found in $PATH 或运行时报 cannot execute binary file: Exec format error。
立即学习“go语言免费学习笔记（深入）”；
- 纯 Go 标准库（如
net/http、os/exec、os/user）在CGO_ENABLED=0下行为一致，只是 DNS 解析会 fallback 到/etc/resolv.conf - 若必须用 cgo（比如数据库驱动强制依赖 sqlite3），就得配对应平台的 C 工具链，例如
CC_linux_arm64=aarch64-linux-gnu-gcc，这已超出 Go 原生能力范围 - 检查是否隐含 cgo：运行
go list -f '{{.CgoFiles}}' ./，输出非空即含 C 文件
交叉编译后怎么验证是不是真的能跑
别光看文件名或 ls -l，得用 file 命令看实际格式：
- Linux 目标：输出应含
ELF 64-bit LSB executable, x86-64（amd64）或ARM aarch64（arm64） - Windows 目标：输出应含
PE32+ executable (console) x86-64或ARM64 - 若出现
dynamically linked，说明CGO_ENABLED没关干净，或第三方包偷偷启用了 cgo
另外，./myapp 在宿主机上执行失败是正常现象——你生成的是给目标系统跑的，不是给自己系统跑的。
嵌入式或老旧平台要注意 GOARM 和构建约束
ARM 架构不是只有 arm64 一种。比如树莓派 Zero 或某些国产 SoC 需要 GOARCH=arm，这时必须额外指定 GOARM=7（或 6）：
GOOS=linux GOARCH=arm GOARM=7 go build -o app .- 若代码里直接用了
syscall.Stat_t这类底层类型，在darwin/amd64和darwin/arm64之间交叉编译会报undefined: syscall.Stat_t——这不是环境问题，是 Go 标准库对不同架构的syscall封装不兼容 - 遇到
build constraints exclude all Go files，先查是否有// +build windows这类约束，再确认GOOS是否匹配
真正麻烦的从来不是参数怎么写，而是你不知道哪行 import 或哪个第三方包悄悄打开了 cgo，或者哪处 syscall 调用锁死了架构兼容性。
