Go交叉编译成功取决于GOOS、GOARCH和CGO_ENABLED三者协同；三者缺一不可，且CGO_ENABLED=0可确保静态链接与跨平台稳定性，否则需配套目标平台C工具链或使用Docker。
Go 本身不依赖宿主机操作系统或 CPU 架构来生成目标二进制，但能否成功交叉编译，取决于三个变量是否协同得当：GOOS、GOARCH 和 CGO_ENABLED。只要三者匹配且环境满足，macOS 上编译 Linux ARM64 完全可行；反之，哪怕只漏设一个，go build 就会静默生成当前平台的二进制——你根本不会收到报错。
GOOS 和 GOARCH 必须同时显式设置
Go 默认只构建当前运行环境的版本，比如在 macOS M1（darwin/arm64）上执行 go build，结果永远是 darwin/arm64，无论你目标是 Windows 还是嵌入式 Linux。
-
GOOS和GOARCH缺一不可：单独设GOOS=linux不生效，单独设GOARCH=arm64也不生效 - 常见合法组合可查：
go tool dist list—— 输出所有当前 Go 版本支持的GOOS/GOARCH对，例如linux/amd64、windows/arm64、darwin/arm64 - ARM32 已基本弃用：
GOARM=7仅用于GOARCH=arm（32 位），现代项目应直接选arm64；GOARCH=loong64需 Go ≥ 1.20 且配好CC=loongarch64-linux-gnu-gcc
CGO_ENABLED=0 是跨平台稳定性的分水岭
启用 CGO（即 CGO_ENABLED=1，默认值）会让 Go 调用 C 标准库和系统 API，此时交叉编译失败率极高——因为宿主机没有目标平台的头文件（如 windows.h）或链接器（如 aarch64-linux-gnu-gcc）。
- 纯 Go 项目（无
// #cgo、未导入C包、未用net的 cgo DNS 或os/user）可安全关闭：CGO_ENABLED=0 GOOS=linux GOARCH=arm64 go build -o app - 含 C 依赖的项目（如
github.com/mattn/go-sqlite3）必须设CGO_ENABLED=1，但需配套目标平台 C 工具链，否则编译失败；此时更推荐用 Docker 模拟目标环境：docker run --rm -v $(pwd):/work -w /work golang:1.21-alpine-arm64 go build -o app -
CGO_ENABLED=0下生成的是完全静态二进制，不依赖libc，可直接扔进无任何工具链的容器或嵌入式设备运行
Windows 编译要注意后缀与入口点
在非 Windows 系统上交叉编译 Windows 可执行文件，容易忽略两个细节：文件扩展名和程序入口。
立即学习“go语言免费学习笔记（深入）”；
- 必须加
.exe后缀：GOOS=windows GOARCH=amd64 go build -o myapp.exe main.go，否则双击打不开 - 若用
func main()（标准入口），生成的 EXE 在 Windows 上可正常运行；若误用 WinMain 风格（需导入C、写func main() { ... }外再定义WinMain），会导致启动失败或黑窗口闪退 - Go 1.21+ 原生支持
GOOS=windows GOARCH=arm64，旧版本（如 1.19）会报unsupported GOOS/GOARCH pair
资源路径和动态依赖不会被自动打包
交叉编译只处理 Go 源码，不会扫描或复制配置文件、模板、SQLite 数据库或共享库。这些必须手动管理，否则程序在目标机器上运行时会因路径错误崩溃。
- 不要硬编码
"config.yaml"，改用filepath.Join(filepath.Dir(os.Args[0]), "config.yaml")或os.Executable()定位二进制所在目录 - 如果程序依赖
libsqlite3.so或libssl.so，而你又启用了 CGO，那这些动态库不会打进二进制里——必须随二进制一起分发，并确保目标系统有对应版本 - 嵌入资源（如 HTML 模板、图标）建议用
embed包（Go 1.16+）：//go:embed templates/*，这样编译后就固化在二进制中，彻底规避路径问题
真正卡住人的从来不是命令写不对，而是编译成功了却在目标机器上 panic：找不到 config、打开不了数据库、甚至连日志都写不进磁盘——因为路径逻辑没适配，或者忘了 embed 资源。交叉编译只是第一步，后续的路径、依赖、资源绑定，才是让二进制真正“可移植”的关键。
