交叉编译必须显式设置goos和goarch，如goos=linux goarch=arm64；cgo_enabled=0需配合使用以防libc依赖；错误组合或隐式cgo依赖会导致二进制在目标机失效。
GOOS和GOARCH环境变量怎么设才有效
交叉编译的核心就两条命令行变量：GOOS 和 GOARCH，它们必须在构建时显式指定，且不能依赖本地系统默认值。Go 不会自动推导目标平台，漏设或拼写错误（比如把 darwin 写成 macos）会导致静默编译出错二进制——看起来成功了，但根本跑不起来。
-
GOOS常见值：linux、windows、darwin（不是mac）、freebsd -
GOARCH常见值：amd64、arm64、386（Windows 32 位用这个，不是x86）、arm（注意：arm默认是 ARMv6，要 v7 得加GOARM=7） - 设置方式优先用命令前缀，比如：
GOOS=linux GOARCH=arm64 go build -o myapp .；不要用export全局设，容易污染后续本地构建 - Windows 上 cmd 要用
set GOOS=linux && set GOARCH=amd64 && go build -o myapp.exe；PowerShell 则用$env:GOOS="linux"; $env:GOARCH="amd64"; go build -o myapp.exe
CGO_ENABLED=0 是不是必须关
只要你的程序没调 C 代码（比如没用 cgo、没 import "C"、没依赖 sqlite、openssl、net 等需系统库的包），就该关掉 CGO_ENABLED。开了它，交叉编译会失败或生成依赖宿主机 libc 的二进制，拿到目标机器上直接报 no such file or directory（其实是找不到 libc.so.6）。
- 纯 Go 网络服务、CLI 工具、定时任务，一律加
CGO_ENABLED=0 - 如果用了
net包但想静态链接 DNS 解析（避免依赖系统/etc/resolv.conf），还得额外加-tags netgo - 开了
CGO_ENABLED=1却没配对应平台的 C 交叉工具链（如x86_64-linux-gnu-gcc），go build会直接报错exec: "gcc": executable file not found
交叉编译后二进制为什么在目标机器上报 “not a valid ELF” 或 “bad CPU type”
这不是 Go 的问题，而是你设错了 GOOS/GOARCH 组合，或者目标机器架构比你编译的更老/更新。Go 编译器不会做运行时兼容性兜底。
- Mac M1/M2（ARM64）上编译
GOOS=darwin GOARCH=amd64，得到的二进制只能跑在 Intel Mac，M1 上执行会报Bad CPU type in executable - Linux ARM64 服务器（aarch64）上运行
GOOS=linux GOARCH=arm编译出的二进制，大概率报not a valid ELF—— 因为arm默认生成 ARMv6 指令集，而 aarch64 内核不兼容 - 验证方法：在目标机器上运行
file ./myapp，看输出是否匹配其架构；本地可用go tool dist list查所有支持组合
vendor 目录和 go.mod 对交叉编译有影响吗
没有直接影响，但 vendor 里混入了平台相关代码（比如某些包的 build tags 分支含 C 文件），或者 go.mod 里间接拉了带 cgo 的依赖（如 github.com/mattn/go-sqlite3），就会让 CGO_ENABLED=0 失效，触发上面说的链接失败。
立即学习“go语言免费学习笔记（深入）”；
- 执行
go list -deps -f '{{if .CgoFiles}}{{.ImportPath}}{{end}}' .可快速检查当前模块是否含 cgo 文件 - 用
go mod graph | grep sqlite类似命令排查隐式 cgo 依赖 - vendor 不解决跨平台问题，反而可能锁死旧版有 cgo 的依赖；建议关掉 vendor，用
GOOS/GOARCH+CGO_ENABLED=0在干净环境中构建
真正麻烦的不是设对两个环境变量，而是依赖树里藏了一个没声明的 //go:build cgo 文件，或者某条 transitive 依赖悄悄打开了 net 的 cgo 分支。这种问题往往要到目标机器上跑起来才暴露，得提前用 file 和 ldd（Linux）或 otool -l（macOS）验货。
