Go原生支持交叉编译，需成对设置GOOS和GOARCH，单独设置无效；CGO_ENABLED=0可生成静态二进制但禁用C依赖库；启用CGO时须配齐目标平台C工具链，推荐用Docker固化环境确保一致性。
Go 原生支持交叉编译，不需要额外装工具链——但前提是别乱开 CGO_ENABLED=1，否则立刻掉坑里。
GOOS 和 GOARCH 必须成对设置，单独改一个等于白干
Go 不会自动推导缺失的变量。比如只设 GOOS=linux，GOARCH 仍沿用你本机值（如 amd64），这看起来“能编”，但实际不是你想要的目标平台；更危险的是，若本机是 macOS，却漏设 GOARCH=arm64，结果生成了 darwin/amd64 而非 darwin/arm64，部署到 M1/M2 机器上直接报 exec format error。
- 查所有合法组合：运行
go tool dist list，输出类似linux/amd64、linux/arm64、windows/386等 - 常见目标示例：
- Linux ARM64：
GOOS=linux GOARCH=arm64 - Windows AMD64：
GOOS=windows GOARCH=amd64 - macOS Apple Silicon：
GOOS=darwin GOARCH=arm64
- Linux ARM64：
- 推荐写法：用
env前置，避免污染当前 shell，例如：env GOOS=linux GOARCH=arm64 go build -o app-linux-arm64 .
CGO_ENABLED=0 是默认安全线，但不是万能解药
设 CGO_ENABLED=0 能绕过 C 工具链问题，生成纯静态二进制，适合绝大多数 CLI、HTTP 服务。但它会让部分标准库行为降级或失效：
-
net包 DNS 解析会 fallback 到 Go 实现，可能无法访问某些企业内网 DNS -
os/user、os/signal在某些平台返回空或 panic - 所有依赖 C 的第三方库（如
github.com/mattn/go-sqlite3、golang.org/x/sys/unix）直接编译失败 - 真正需要 CGO 时，必须配齐目标平台的 C 工具链，例如：
CC_linux_arm64=aarch64-linux-gnu-gcc，并确保头文件和 sysroot 可达
交叉编译失败时，先看构建日志里有没有 gcc 调用
很多人以为没报错就是成功了，其实 Go 在 CGO_ENABLED=1 下找不到对应 CC 时，会静默降级为 CGO_ENABLED=0，不报错也不提醒——但你的程序在目标机器上一跑就 panic。
立即学习“go语言免费学习笔记（深入）”；
- 验证是否真用了交叉 C 编译器：加
-x参数重试，例如：env CGO_ENABLED=1 GOOS=linux GOARCH=arm64 CC=aarch64-linux-gnu-gcc go build -x -o app . - 检查输出中是否有类似
aarch64-linux-gnu-gcc -I ...的行；没有？说明 Go 根本没调用你指定的编译器 - 常见漏点：
CGO_CFLAGS没加-isysroot，CGO_LDFLAGS没指定--sysroot，导致stdio.h: No such file or directory - Ubuntu/Debian 用户快速安装工具链：
sudo apt install gcc-aarch64-linux-gnu g++-aarch64-linux-gnu
Docker 是最省心的交叉编译方案，尤其涉及 CGO
本地配工具链容易路径错、版本混、权限乱；Docker 镜像把 GOOS/GOARCH/CC/CGO_CFLAGS 全部固化，一次写对，到处可用。
- 基础镜像选带交叉工具链的，比如
golang:1.22-bookworm+ 手动apt install gcc-arm64-linux-gnu - 或者直接用社区维护的多平台镜像，如
tonistiigi/xx或kennethreitz/xgo - 关键点：容器内执行时，
GOOS/GOARCH是环境变量，CC必须指向容器内已安装的交叉编译器路径，不能复用宿主机的 - 不要在 Docker 里 export 全局环境变量——用
env前置或docker run -e显式传入更可控
真正难的从来不是“能不能编出来”，而是“编出来的二进制在目标机器上能不能跑通第一行代码”。尤其是启用了 CGO 的项目，file 命令看到 ELF 或 PE 头只是起点，ldd（Linux）、otool -L（macOS）、Dependency Walker（Windows）才是照妖镜。
