跨平台编译失败首要检查goos和goarch是否正确设置，必须用darwin/windows等全称而非mac/win，amd64不可写为x86_64；runtime.goos返回运行环境而非编译目标，应优先用构建标签做编译期分支；启用cgo会导致交叉编译失效，推荐cgo_enabled=0；路径、换行、权限等需显式适配平台。
跨平台编译失败时，GOOS 和 GOARCH 设对了吗
Go 的跨平台编译能力依赖环境变量控制，不是靠运行时检测。如果 go build 输出的二进制在目标系统上无法运行（比如 macOS 上编译出的 Linux 二进制在容器里报 exec format error），第一反应该检查这两个变量是否显式指定，而非猜测代码有没有写错。
常见组合必须手动设置：
GOOS=linux GOARCH=amd64 go build -o app-linuxGOOS=darwin GOARCH=arm64 go build -o app-macGOOS=windows GOARCH=386 go build -o app-win.exe
注意：GOOS 值不支持 mac 或 win 这类缩写，必须用 darwin、windows；GOARCH 中 amd64 不能写成 x86_64。
调用系统 API 时，runtime.GOOS 不是跨平台安全的判断依据
编译期决定目标平台，但 runtime.GOOS 返回的是**当前运行环境**的 OS 名。如果你在 Linux 上交叉编译 Windows 程序，代码里写 if runtime.GOOS == "windows"，这个判断在构建时不会生效，而是在 Windows 上运行时才执行——这容易造成逻辑错位，比如误加载 Linux 专用配置或路径分隔符。
更稳妥的做法是用构建标签（build tags）做编译期分支：
//go:build windows
// +build windows
package main
import "os"
func getHomeDir() string {
return os.Getenv("USERPROFILE")
}
//go:build !windows
// +build !windows
package main
import "os"
func getHomeDir() string {
return os.Getenv("HOME")
}
这样不同平台会编译进各自适配的函数，不会混入无用逻辑，也不依赖运行时判断。
CGO 启用后，跨平台编译基本失效
只要代码里 import 了 C，或者设置了 CGO_ENABLED=1（默认值），Go 就会尝试调用宿主机的 C 工具链和系统头文件。此时即使设了 GOOS=windows，也会因找不到 Windows 的 gcc 或 windows.h 而失败。
解决路径只有两条：
- 彻底禁用 CGO：编译前设
CGO_ENABLED=0，适用于纯 Go 实现的功能（如网络、JSON、加密等） - 使用对应平台的交叉编译工具链（如
x86_64-w64-mingw32-gcc），并配置好CC_for_target，但这大幅增加 CI 配置复杂度，且容易因头文件版本不一致出错
多数 CLI 工具或服务程序应优先选 CGO_ENABLED=0，它还能让二进制变成静态链接、免依赖 libc，真正“扔过去就能跑”。
路径、换行、权限等隐性系统差异必须显式处理
看似中立的操作，背后常藏平台陷阱：
- 硬编码
"\\"或"/"当路径分隔符 → 应用path/filepath包里的Join、Separator - 用
" "写日志或配置文件 → Windows 用户打开可能显示为单行 → 用fmt.Fprintln或strings.ReplaceAll(s, " ", " ")按需转换 -
os.Chmod设置可执行位 → 在 Windows 上静默失败，且不会报错 → 可先runtime.GOOS == "windows"判断再跳过
这些点不会导致编译失败，但会让程序在某个平台上行为异常，而且很难通过本地测试发现——你得真正在目标系统上跑一遍才能确认。
跨平台真正的难点不在编译命令，而在那些没报错、却悄悄失效的“理所当然”。
