Go交叉编译无需额外工具链，但必须显式设置GOOS和GOARCH，缺一不可；CGO_ENABLED=0是多数场景下的必需开关，否则易因C库不匹配导致构建失败或运行时错误。
Go 交叉编译不需要额外工具链，但 GOOS 和 GOARCH 必须显式设置，否则根本不会跨平台；CGO_ENABLED=0 不是可选项，而是多数场景下的生存线。
GOOS 和 GOARCH 必须每次显式传入命令行
不设 GOOS/GOARCH 就等于没交叉编译——go build 默认只生成当前系统能跑的二进制。临时赋值比 go env -w 更安全，避免污染后续构建。
-
GOOS=linux GOARCH=arm64 go build -o app-linux-arm64 .—— 编译 Linux ARM64 可执行文件 -
GOOS=windows GOARCH=amd64 go build -o app.exe .—— 注意：.exe 后缀得自己加，Go 不会自动补 -
GOOS=darwin GOARCH=arm64 go build -o app-macos .—— macOS Apple Silicon 唯一支持的 ARCH 是 arm64 或 amd64，GOARCH=386在 darwin 下直接报错 - Windows 上编译 32 位程序需
GOARCH=386，但现代 Windows Server 默认禁用 WoW64，建议优先用amd64或arm64
CGO_ENABLED=0 是默认必须加的开关
只要目标平台不是当前宿主机（比如 macOS 编译 Linux），开启 CGO 就大概率失败：链接时找不到 glibc、musl 或 Windows C 运行时，运行时报 cannot execute binary file: Exec format error 或 no such file or directory（其实是动态库缺失）。
- 纯 Go 项目（没
import "C"、没调用 net.LookupIP 等隐式触发 cgo 的行为）—— 一律加CGO_ENABLED=0 - 用了
os/user、net等包时，CGO_ENABLED=0下user.Current()可能 panic，net.DefaultResolver会 fallback 到纯 Go DNS 解析（读/etc/resolv.conf，不走 libc） - 如果代码里有空 import
"C"，或依赖含 cgo 的第三方包（如旧版github.com/mattn/go-sqlite3），CGO_ENABLED=0会直接报gcc: command not found；可用go list -f '{{.CgoFiles}}' ./...快速扫描
验证交叉编译结果不能只看文件名
生成 app.exe 不代表它真能在 Windows 上跑；生成 app-linux-arm64 也不代表它没动态依赖。必须用底层工具确认格式与链接状态。
立即学习“go语言免费学习笔记（深入）”；
- Linux 目标：用
file app-linux-arm64看是否含ELF 64-bit LSB executable, ARM aarch64；再用ldd app-linux-arm64，若输出not a dynamic executable才算静态干净 - macOS 目标：用
file app-macos确认Mach-O 64-bit executable arm64；用otool -L app-macos检查是否引用了/usr/lib/libSystem.B.dylib以外的路径（如有，说明非纯 Go 或 CGO 被意外启用） - Windows 目标：在 Linux/macOS 上无法用 ldd，但可用
wine app.exe快速试跑（仅限简单逻辑）；更可靠的是上传到 Windows 虚拟机或 GitHub Actions 的windows-latestrunner 中验证
含 CGO 的项目别硬扛交叉编译
一旦项目或依赖中出现 import "C"，原生 Go 交叉编译基本失效。强行配 CC_arm64_linux_gnu 等环境变量，等于手动搭 C 交叉工具链——复杂度陡增，且容易因头文件路径、sysroot、libc 版本不一致而卡死。
- 首选方案：剥离 cgo 依赖，换纯 Go 实现（如用
golang.org/x/sys/unix替代部分 syscall，用github.com/ziutek/mymysql替代 sqlite3） - 次选方案：改用 Docker 构建——用
golang:1.23-alpine镜像，在容器内设GOOS=linux GOARCH=arm64，再装对应 C 工具链（如aarch64-linux-gnu-gcc），本质是“换平台编译”而非“真交叉” - 特别注意：
CGO_ENABLED=1时，GOOS=windows无法使用 MinGW 工具链自动识别，必须显式设CC_x86_64_w64_mingw32等，实操中几乎没人走通
最容易被忽略的一点：GOOS/GOARCH 是编译期决定的，但某些 Go 标准库行为（如 time.Now().Zone() 返回的时区名）仍受宿主机 /etc/timezone 影响——交叉编译解决不了运行时环境差异，该打的 patch 得在代码里打。
