Go原生支持交叉编译，只需GOOS和GOARCH被官方支持且禁用cgo（CGO_ENABLED=0）；运行go tool dist list可查支持组合，含cgo或平台特定syscall需额外工具链或构建标签隔离。
Go 原生支持交叉编译，不需要额外安装工具链或配置 CGO_ENABLED=0 就能生成目标平台二进制——但前提是目标平台的 GOOS 和 GOARCH 组合被 Go 官方支持，且你没用到 cgo 依赖。
确认目标平台是否被 Go 原生
Go 自 1.5 起内置了对多数常见平台的支持，无需下载额外 SDK。运行 go tool dist list 可查所有支持组合，例如：
linux/amd64 linux/arm64 windows/amd64 darwin/arm64 freebsd/386
如果你看到 linux/mips64le 或 windows/386 在列表里，说明直接可用；若目标是 android/arm64，则需额外配置 NDK（它不属于 Go 原生交叉编译范畴）。
常见误判点：
-
darwin/arm64（M1/M2 Mac）不能用来编译 iOS 应用——iOS 不在go tool dist list中，不支持 -
linux/ppc64le需要 Go 1.19+，旧版本会报build constraints exclude all Go files - 即使列表里有，若项目含
#include等 C 头文件，仍可能因 cgo 触发本地系统调用而失败
禁用 cgo 是跨平台稳定性的关键
只要项目或任一依赖用了 cgo（比如 os/user、net 包在某些系统下会触发），默认编译会链接宿主机 libc，导致目标平台无法运行。最稳妥做法是彻底关闭 cgo：
- 编译前设置环境变量：
CGO_ENABLED=0 - 推荐在命令中显式带上：
CGO_ENABLED=0 GOOS=linux GOARCH=arm64 go build -o myapp . - 若必须启用 cgo（如要用 SQLite 的 CGO 版本），就得为每个目标平台安装对应 C 工具链（如
aarch64-linux-gnu-gcc），并设CC_aarch64_linux_gnu等变量——这已超出“纯 Go 交叉编译”范畴
注意：CGO_ENABLED=0 下，net 包会回退到纯 Go 实现（慢但可移植），os/user 会无法解析用户名（返回空字符串或 error），这些行为要在测试中验证。
Windows 和 macOS 上编译 Linux 二进制是否可靠？
可靠，只要满足两个条件：
- 你的 Go 版本 ≥ 1.16（此前
net包在CGO_ENABLED=0下有 DNS 解析 bug） - 没引入任何平台特定的 syscall 或 cgo 依赖（比如
golang.org/x/sys/windows在 Linux 编译时会直接报错）
典型失败场景：
import _ "golang.org/x/sys/unix" → 在 Windows 宿主机上编译 linux/arm64 会报 build constraints exclude all Go files，因为该包不含 Windows 实现；删掉或用构建标签隔离即可。
另一个坑：//go:build linux 标签若写成 // +build linux（旧语法），在 Go 1.17+ 默认被忽略，导致非预期代码被编译进去。
交叉编译后如何验证平台兼容性？
别只看文件名，用系统命令确认：
- Linux/macOS 下：
file myapp输出应含ELF 64-bit LSB executable, x86-64或ARM aarch64 - Windows 下用 PowerShell：
Get-Command .\myapp.exe | Select-Object -ExpandProperty FileVersionInfo不够准，建议上传到目标环境用.\myapp.exe直接运行 - 最小化验证：在目标平台容器里跑一次：
docker run --rm -v $(pwd):/work -w /work golang:1.22-alpine sh -c "./myapp --help"
最容易被忽略的是动态链接问题——哪怕 CGO_ENABLED=0，如果用了 sqlite3 的 cgo 模式，或通过 syscall.Exec 调用外部程序，依然会因缺失 so 文件或路径差异崩溃。这种问题不会在编译时报错，只能靠目标环境实测。
