goos和goarch需按目标平台设为合法小写组合，如linux/amd64、darwin/arm64；非法组合会导致构建失败，全量支持列表应以go tool dist list输出为准。
GOOS和GOARCH到底该设成啥值
Go交叉编译能不能成功，第一关就是这两个环境变量填对没。填错最直接的表现是：build constraints exclude all Go files 或者 cannot find package "C"（尤其在调用cgo时）。不是所有组合都合法，比如GOOS=windows GOARCH=arm64从Go 1.16才支持，而GOOS=js GOARCH=wasm压根不走传统编译链路。
常用组合得记牢：linux/amd64、darwin/arm64（M1/M2 Mac）、windows/386（32位老系统）、linux/arm64（树莓派5、AWS Graviton）。别凭感觉写arm——Go里必须是arm64或arm（对应ARMv7），没有armv8这种写法。
-
GOOS只认小写：用windows，别写Windows或WIN -
GOARCH大小写敏感：amd64不能写成AMD64 - 查全量支持列表？运行
go tool dist list，输出即权威，别信网上过时的表格
cgo启用时交叉编译必踩的坑
一旦代码里有#include或// #cgo注释，交叉编译就从“设两个变量”升级成“配一整套工具链”。默认CGO_ENABLED=1时，Go会尝试调用宿主机的gcc，结果编译Linux二进制却调了macOS的clang——必然失败。
正确做法是显式关闭cgo，或指定目标平台的交叉编译器：
立即学习“go语言免费学习笔记（深入）”；
- 纯Go项目（无C依赖）：加
CGO_ENABLED=0，立刻解决90%的交叉编译问题 - 必须用cgo（比如调
libsqlite3）：得装对应gcc交叉工具链，例如Linux ARM64需aarch64-linux-gnu-gcc，再通过CC_aarch64_linux_gnu=...指定 - Mac上编译Windows程序？
CGO_ENABLED=0几乎是唯一靠谱选择，否则要折腾MinGW-w64，得不偿失
构建命令里-CGO_ENABLED和-buildmode怎么配
-buildmode影响最终产物类型，和CGO_ENABLED强相关。常见错误是以为设了GOOS就万事大吉，结果生成了个不能跑的.a文件或者动态链接库。
记住三组固定搭配：
- 生成可执行文件（最常用）：
CGO_ENABLED=0 go build -o app（静态单文件） - 需要cgo且生成exe：
CGO_ENABLED=1 CC_x86_64_w64_mingw32=gcc-x86_64-w64-mingw32-gcc go build -o app.exe -buildmode=default - 生成插件（
.so）：CGO_ENABLED=1 go build -buildmode=plugin -o plugin.so，此时GOOS/GOARCH必须和宿主机一致，插件不能跨平台
特别注意：-buildmode=c-archive和c-shared产出的是C兼容库，不是直接运行的二进制，别拿去当./app执行。
交叉编译后文件体积暴增或运行报错
编译出来的二进制比预期大几倍？或者提示no such file or directory（其实是找不到动态库）？大概率是静态链接没做干净，或者目标系统缺基础库。
排查重点在链接方式和符号表：
- 用
file app看是否为statically linked；若显示dynamically linked，说明cgo启用了但没配对工具链 - Linux上用
ldd app检查依赖（仅对动态链接有效）；如果报not a dynamic executable，恭喜，你已经静态编译成功 - Mac上编译的
darwin/arm64二进制，在Intel Mac（darwin/amd64）上无法运行，Rosetta也不行——架构真不兼容 - 加
-ldflags="-s -w"能砍掉调试信息，体积通常减少30%以上，但别在调试阶段用
真正麻烦的是那些隐式依赖：比如日志里打了个time.Now().Zone()，在Alpine Linux上可能因缺失/usr/share/zoneinfo而panic——这种得靠容器里实测，光看编译不出错没用。
