确认当前支持的GOOS/GOARCH组合需运行go tool dist list，它输出本机Go版本原生支持的所有合法组合（如linux/amd64、windows/arm64），未列出的组合强行使用会报错；环境变量必须命令行临时设置（如GOOS=linux GOARCH=arm64 go build），避免export污染shell；CGO_ENABLED=0几乎必加，确保纯Go实现、静态链接、零依赖部署。
GOOS 和 GOARCH 不是“配置项”，而是编译时生效的环境变量，设错或漏设一个，就可能生成无法在目标机器运行的二进制文件。
怎么确认当前支持哪些 GOOS/GOARCH 组合？
别猜，直接查。运行：go tool dist list
它会输出所有本机 Go 版本原生支持的组合，比如 linux/amd64、windows/arm64、darwin/arm64 等。
注意：不是所有组合都可用——GOOS=freebsd GOARCH=arm64 可能不列在结果里，强行用会报 build constraints exclude all Go files。
为什么命令行临时设置比 export 更安全？
临时设置避免污染当前 shell 环境，尤其在 CI/CD 或多项目并行开发中很关键：
- ✅ 推荐写法：CGO_ENABLED=0 GOOS=linux GOARCH=arm64 go build -o app-linux-arm64 .
- ❌ 危险写法：export GOOS=linux; export GOARCH=arm64; go build -o app .
后者会让后续所有 go build 默认走 Linux ARM64，哪怕你只是想本地跑一下测试，也会静默失败。
CGO_ENABLED=0 为什么几乎总是要加？
绝大多数纯 Go 项目不需要 C 代码，但一旦启用 CGO（比如用了 net.LookupIP 在某些旧系统上、或引入了 sqlite3），交叉编译就会卡在 exec: "gcc": executable file not found in $PATH。
加 CGO_ENABLED=0 后：
- 所有标准库调用走纯 Go 实现（如 os/exec、net/http）
- 生成完全静态链接的二进制，不依赖目标机的 libc 或 gcc
- 体积可能略大，但部署零依赖，适合容器和嵌入式环境
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
立即学习“go语言免费学习笔记（深入）”；
Windows 上编译出的 .exe 在 Linux 里报 Exec format error 怎么办？
这不是编译失败，而是你误在 Linux 上执行了 Windows 二进制：
- 先用 file app.exe 确认它是 PE32+ executable (console) x86-64，说明编译成功
- 真正该检查的是：是否把 GOOS=windows 的产物发到了 Linux 服务器上运行？
常见疏忽：
- 忘记改 GOOS，只改了 GOARCH
- IDE（如 Goland）里设置了全局 GOOS，但终端没重置
- 脚本里变量拼错，比如写成 GOAS 或漏空格
真正容易被忽略的点是：GOOS 和 GOARCH 必须同时显式指定，且不能依赖宿主机默认值——哪怕你在 macOS 上编译 darwin/amd64，也建议写全，避免因 Go 版本升级导致隐式行为变化。
