go交叉编译成功的关键是每次build前显式设置goos、goarch和cgo_enabled=0三者缺一不可；漏设任一变量或启用cgo，易导致目标机器报cannot execute binary file或no such file or directory。
Go 交叉编译不是“配环境”，而是每次 go build 前显式设置三个变量：必须同时指定 GOOS 和 GOARCH，且几乎总要加 CGO_ENABLED=0；漏一个，生成的二进制在目标机器上大概率直接报 cannot execute binary file 或 no such file or directory。
GOOS 和 GOARCH 必须成对显式设置，不能只设一个
Go 不会补全、不警告、不猜测。只设 GOOS=linux 不设 GOARCH，它就用你当前机器的架构（比如 macOS M1 上默认出 darwin/arm64）；只设 GOARCH=arm64 不设 GOOS，结果还是 darwin/arm64。
- 正确写法：
GOOS=linux GOARCH=arm64 go build -o app-linux-arm64 . - Windows 目标要自己加
.exe后缀：GOOS=windows GOARCH=amd64 go build -o app.exe . - 查所有合法组合别硬记：
go tool dist list，输出如linux/amd64、windows/arm64、darwin/arm64 -
darwin已弃用386，GOOS=darwin GOARCH=386会直接报错
CGO_ENABLED=0 是默认必须加的开关，不是可选项
开启 CGO_ENABLED=1 会让 Go 尝试调用宿主机的 gcc 并链接本地 C 库（如 macOS 的 libSystem.dylib、Linux 的 glibc）。你在 macOS 上编译 Linux 二进制，它却去找 glibc——链接失败；就算侥幸过掉，运行时也常因 libc 版本不匹配 panic。
- 纯 Go 项目（没
import "C"、没用github.com/mattn/go-sqlite3等含 cgo 的包）：一律加CGO_ENABLED=0 - 检查有没有 cgo 文件：
go list -f '{{.CgoFiles}}' ./，返回非空切片说明有依赖 - 关 CGO 后，
net包 DNS 解析会 fallback 到 Go 自实现（读/etc/resolv.conf），os/user.Current()可能返回空或 panic——这是预期行为，不是 bug
遇到 import "C" 就得面对现实：要么删，要么配工具链
只要源码树里任意一个 .go 文件写了 import "C"（包括第三方包），整个构建就强制进入 cgo 模式。此时 CGO_ENABLED=0 会直接报错：cannot use cgo when CGO_ENABLED=0；不关又链接失败。
- 若必须保留 cgo（比如要用 SQLite 或 OpenSSL），就得为目标平台配交叉 C 工具链，例如 Linux ARM64 需设：
CC=aarch64-linux-gnu-gcc CGO_ENABLED=1 GOOS=linux GOARCH=arm64 go build ... - 对应工具链安装（Ubuntu）：
sudo apt install gcc-aarch64-linux-gnu g++-aarch64-linux-gnu - ARMv7 等旧架构还需额外设
GOARM=7，且GOARM仅对GOARCH=arm有效
真正容易被忽略的是：跨平台不是“一次编写到处运行”的自动魔法，而是每次构建都得亲手确认这三个变量是否齐全、是否匹配、是否和你的依赖兼容——尤其当引入新第三方包时，go list -f '{{.CgoFiles}}' 这条命令比 go build 更早告诉你能不能走纯静态路线。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
