GOOS和GOARCH必须同时显式设置，缺一不可；仅设其一将生成当前平台二进制，导致运行时报Exec format error；CGO_ENABLED=0是稳定交叉编译的默认安全开关。
GOOS和GOARCH必须同时显式设置，缺一不可
只设 GOOS=linux 而不设 GOARCH，Go 会沿用当前机器的架构（比如你 Mac 是 arm64，结果就是 linux/arm64；但你要的是 linux/amd64，那就错了）。Go 不会“猜”目标平台，也不会 fallback 到默认值——它只是照抄未显式覆盖的那个变量。
常见错误现象：cannot execute binary file: Exec format error，基本就是组合没对上。验证当前值用：go env GOOS GOARCH，别信 IDE 或 CI 脚本里残留的设置。
-
go tool dist list输出所有支持的组合，不在列表里的直接失败（比如freebsd/riscv64在 Go 1.18 就不支持） - Windows 用户在 PowerShell 中要用：
$env:GOOS="windows"; $env:GOARCH="amd64"，不能直接写GOOS=windows - Bash/Zsh 用户推荐用
env GOOS=linux GOARCH=arm64 go build -o app .，避免污染 shell 环境
CGO_ENABLED=0 是交叉编译的默认安全开关
只要代码没 import "C"，也没依赖 SQLite、OpenSSL 等必须 cgo 的第三方库，就该关掉 CGO。否则 Go 会尝试链接宿主机的 C 库（比如 macOS 的 libSystem、Linux 的 glibc），而目标平台根本没有对应动态库，运行时直接 panic 或找不到符号。
检查是否含 cgo 文件：go list -f '{{.CgoFiles}}' ./，返回非空切片说明有 import "C" 或 cgo 注释。
立即学习“go语言免费学习笔记（深入）”；
- 关 CGO 编译：
CGO_ENABLED=0 GOOS=windows GOARCH=amd64 go build -o app.exe . - 开 CGO 编译（仅限必要场景）：
CGO_ENABLED=1 CC_x86_64_w64_mingw32=gcc-x86_64-w64-mingw32 GOOS=windows GOARCH=amd64 go build .——此时你得自己装好交叉 C 工具链，且极易卡在gcc: command not found - 关 CGO 后，
net包 DNS 解析 fallback 到 Go 自实现（读/etc/resolv.conf），os/user可能返回空或 panic——这是预期行为，不是 bug
build constraints exclude all Go files 是最常被忽略的构建失败信号
这个错误不是编译器坏了，是 Go 扫完所有 .go 文件，发现每个都被构建约束跳过了。典型原因有两个：
- 文件顶部写了
// +build windows，但你当前GOOS=linux，该文件被排除；其他文件也类似，最后没剩一个可编译的 - 用了平台限定函数却没做适配，比如
_linux.go里调了syscall.Kill，_windows.go里用了windows.CloseHandle，而构建时没匹配到对应文件 - 注意：Go 1.17+ 已弃用
// +build，改用//go:build，但两者共存时仍生效，容易误判
darwin/amd64 和 darwin/arm64 之间不能随意互编
macOS 上从 arm64 编译到 amd64 报错 undefined: syscall.Stat_t？这不是架构问题，是 Go 标准库里部分 syscall 类型在不同 GOARCH 下字段名或内存布局不同。Go 不保证同 OS 跨架构的 syscall 兼容性——尤其当你手动用了 syscall 包里的结构体时。
解决办法很简单：避免直接操作 syscall.Stat_t、syscall.Utsname 这类底层类型，优先用 os.Stat()、runtime.Version() 等封装好的接口。
另外，GOOS=darwin 编译出的二进制默认无图标、无 manifest，这不是编译问题，是资源嵌入缺失——Go 本身不处理 macOS 资源束（.app bundle）或 Windows PE 资源段。
