Go语言跨平台编译关键在于正确设置GOOS和GOARCH环境变量并关闭CGO_ENABLED=0；漏设任一变量或未关CGO易导致格式错误、动态链接失败或构建失败。
Go 语言跨平台编译不是“能不能”的问题，而是“怎么设对环境变量+关不关 CGO”的问题。只要代码没硬依赖某平台特有 syscall 或 C 库，95% 的项目都能直接交叉编译成功。
GOOS 和 GOARCH 必须同时显式设置
只设 GOOS=linux 而不设 GOARCH，Go 会沿用当前机器的架构（比如你 Mac 是 arm64，它就默认 GOARCH=arm64）；但如果你在 macOS 上想编译 linux/amd64 却漏了 GOARCH，结果就是生成一个 linux/arm64 二进制——根本跑不起来。
- 正确写法（推荐用
env前置，避免污染 shell 环境）：env GOOS=linux GOARCH=amd64 go build -o myapp-linux . - 错误写法：
export GOOS=linux; go build -o myapp .（GOARCH没设，结果不可控） -
GOOS常见值：linux、windows、darwin、freebsd -
GOARCH常见值：amd64、arm64、386（注意不是aarch64）
CGO_ENABLED=0 是稳定交叉编译的默认开关
默认开启 CGO 时，Go 会尝试链接宿主机的 C 库（如 glibc）。你在 macOS 上编译 Linux 二进制，本地没有 ld-linux-x86-64.so.2，要么链接失败，要么生成的程序在目标机上 panic。
- 绝大多数纯 Go 项目应强制关闭：
CGO_ENABLED=0 GOOS=windows GOARCH=amd64 go build -o app.exe . - 关 CGO 后，
net包 DNS 解析自动 fallback 到 Go 原生实现（读/etc/resolv.conf），os/user可能返回空或 panic —— 这是预期行为，不是 bug - 如果代码里有
import "C"（哪怕只是第三方包带的），CGO_ENABLED=0会直接报错：cannot use cgo when CGO_ENABLED=0 - 查 cgo 文件：运行
go list -f '{{.CgoFiles}}' ./...
Windows 编译结果自动加 .exe 后缀，但别信文件名
GOOS=windows 时，go build -o myapp 生成的是 myapp.exe，这是 cmd/go 内部逻辑，无法禁用。但光看后缀不能判断是否真的能用。
- 验证方法一（看格式）：
file myapp.exe→ 应显示PE32+ executable (console) x86-64 - 验证方法二（看链接）：
ldd myapp.exe在 Linux 上会报错（因为不是 ELF），但在 Windows 或 WSL 里用objdump -x myapp.exe | grep DLL可查是否静态链接 - 常见坑：macOS 上编译的
.exe默认用\n换行，某些老旧 Windows 工具可能解析异常；图标、UAC 清单等资源需额外工具（如goversioninfo）嵌入
build constraints exclude all Go files 是最常被忽略的信号
这个错误不是编译器坏了，是 Go 扫了一圈，发现所有 .go 文件都被构建约束排除了。典型原因有两个：
- 文件顶部写了
// +build windows，但你当前GOOS=linux，该文件被跳过；其他文件也类似，最后没剩一个可编译的 - 用了平台限定函数却没做适配，比如在
_linux.go里调了syscall.Kill，又在_windows.go里用了windows.CloseHandle，但公共接口文件没加任何构建标签，导致它被所有平台编译，而其中某些调用在非目标平台根本不存在 - 解决思路：先确保至少有一个无构建标签的公共文件（如定义接口），再把具体实现拆到
_linux.go、_windows.go等带标签的文件中
真正麻烦的从来不是命令怎么写，而是哪一行代码悄悄触发了 CGO，或者哪个第三方包在你不知情时 import 了 "C" —— 这些地方不挖出来，交叉编译永远在边缘反复失败。
