goos和goarch是go编译器用于指定目标操作系统的类型（如linux、windows）和cpu架构（如amd64、arm64）的环境变量，二者需同时设置以确保正确交叉编译。
GOOS 和 GOARCH 是什么，不是“编译目标平台”的别名
它们是 Go 编译器用来决定生成哪类二进制的两个环境变量，GOOS 控制操作系统类型（如 linux、windows、darwin），GOARCH 控制 CPU 架构（如 amd64、arm64、386）。关键点在于：Go 不需要安装对应平台的 SDK 或交叉工具链，只要源码不调用平台特有 API（比如 syscall 里未封装的 Windows 句柄操作），就能直接编译出可运行的二进制。
常见错误现象：build constraints exclude all Go files —— 往往是因为代码里用了 // +build windows 这类构建约束，但当前 GOOS 设为 linux，导致所有文件被跳过；或者引入了只在某平台实现的 net.InterfaceAddrs() 等函数，而没做适配。
-
GOOS和GOARCH必须同时设置，单独改一个可能触发隐式默认（比如只设GOOS=windows，GOARCH会沿用宿主机值） - macOS 上编译
darwin/arm64二进制没问题，但编译darwin/amd64需确认 Go 版本是否支持（1.16+ 默认启用CGO_ENABLED=0，否则可能链接失败） - Windows 下生成的
.exe文件默认无图标、无 manifest，这不是编译问题，是资源嵌入缺失
实际编译命令怎么写，避免 shell 变量污染
最安全的方式是用 env 前置设置，而不是先 export GOOS=xxx 再 go build —— 后者会影响后续命令，且容易在 CI 脚本里漏重置。Mac 用户尤其注意 zsh 的环境继承行为，别让终端历史里的 export 残留干扰当前构建。
正确写法示例：
立即学习“go语言免费学习笔记（深入）”；
env GOOS=linux GOARCH=arm64 go build -o myapp-linux-arm64 .
错误写法示例（看似省事，实则危险）：
export GOOS=linux; export GOARCH=arm64; go build -o myapp .
- 交叉编译时
CGO_ENABLED默认为0，若项目依赖 cgo（如 SQLite、某些加密库），必须显式开启并提供对应平台的 C 工具链，否则报exec: "gcc": executable file not found - 使用
go build -ldflags="-s -w"可减小体积，但-s会丢弃符号表，影响 panic 堆栈可读性，调试阶段慎用 - 想验证生成的二进制是否真能跑在目标平台？用
file myapp-linux-arm64看 ELF 类型，或在 Docker 里快速测试：docker run --rm -v $(pwd):/work ubuntu:22.04 /work/myapp-linux-arm64
为什么本地能编译成功，放到 GitHub Actions 就失败
典型原因是 Actions runner 的 Go 版本太旧（比如 v1.18），不支持某些新架构组合（如 GOOS=freebsd GOARCH=riscv64），或默认启用了模块验证（GOPROXY=direct 时私有模块拉不到）。更隐蔽的问题是：你的 go.mod 里写了 go 1.21，但 CI 使用的是 1.19，导致 embed 或泛型语法解析失败，报错却显示成 no Go files in ... 这类误导信息。
- CI 中务必显式指定 Go 版本，GitHub Actions 推荐用
actions/setup-go@v4并 pin 到 patch 版本（如1.21.10） - 如果项目用了
//go:embed，确保GOOS/GOARCH设置不影响 embed 路径解析 —— 它只和源码路径有关，和目标平台无关 - Windows 目标下生成的二进制若含中文日志，需确认源码文件编码为 UTF-8 无 BOM，否则运行时可能输出乱码（Go 自身不处理 BOM，Windows 控制台默认用 GBK）
跨平台编译不是万能的，这些情况它救不了你
Go 的交叉编译能力边界很清晰：它只管生成目标平台能加载的可执行格式，不管运行时依赖是否齐全。比如你在 Linux 上编译出 linux/amd64 二进制，但它动态链接了 libssl.so.3，而目标服务器只有 libssl.so.1.1，照样启动失败；又比如用了 os/exec 调用 systemctl，那编译到 macOS 就直接 panic。
- 纯静态链接可用
CGO_ENABLED=0，但前提是项目完全不依赖 cgo；一旦用了net包的 DNS 解析，默认走 cgo，此时需加GODEBUG=netdns=go强制用 Go 实现 - GUI 应用（如 Fyne、Wails）通常依赖系统原生库（Cocoa、WinAPI、GTK），交叉编译只能产出“能跑起来”的二进制，不能替代目标平台上的开发与测试
- 涉及硬件交互（USB、GPIO）、内核模块、特定驱动的代码，几乎无法靠单纯改
GOOS/GOARCH解决
真正麻烦的从来不是参数怎么设，而是你得清楚自己写的代码，到底哪一行在哪个平台会突然失效。
