GOOS和GOARCH需在Run Configuration中显式设置，GoLand不自动注入；跨平台编译需注意CGO_ENABLED和依赖兼容性，推荐用脚本批量构建，且runtime.GOOS与os.Getenv("GOOS")含义不同。
GOOS 和 GOARCH 环境变量必须在终端或 Run Configuration 里显式设置
GoLand 本身不自动注入 GOOS 或 GOARCH，它们是 Go 工具链的构建时环境变量，只在执行 go build、go run 等命令时生效。你在终端里直接 GOOS=linux GOARCH=arm64 go build 能跑通，但在 GoLand 默认 Run 配置里会失败——因为 IDE 没把这两个变量传给子进程。
在 Run Configuration 中添加环境变量最可靠
这是日常开发中最常用、也最不容易出错的方式：
- 点击右上角运行配置下拉箭头 → Edit Configurations…
- 选中你的 Go Application 配置 → 展开 Environment variables 区域
- 点击右侧
…按钮，添加键值对：GOOS=windows、GOARCH=386（或你需要的组合） - 勾选 Include system environment variables，避免覆盖
GOROOT、GOPATH等基础变量 - 保存后运行，
go env GOOS GOARCH在程序内也能读到对应值
跨平台编译时注意 CGO_ENABLED 和依赖兼容性
设置了 GOOS/GOARCH 后仍编译失败？大概率是以下两个原因：
GoLand 2026.1.1
下载
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
-
CGO_ENABLED=1时，交叉编译会尝试调用目标平台的 C 工具链（比如 Windows 的gcc），但宿主机没有——解决方案是临时禁用：CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build - 某些第三方包（如
github.com/mattn/go-sqlite3）含 C 代码，CGO_ENABLED=0会导致构建失败；此时需改用纯 Go 实现的替代包（如modernc.org/sqlite），或在目标平台机器上构建 - Windows 下生成 Linux 二进制文件时，
go build不报错但运行提示cannot execute binary file: Exec format error，说明没真正交叉编译成功——检查是否漏设GOARCH，或误用了GOOS值（如写成windows而非linux）
批量测试多架构建议用 Shell 脚本 + Terminal，而非硬配多个 Run Configuration
如果你要频繁验证 darwin/amd64、linux/arm64、windows/386 多种组合，为每个都建一个 Run Configuration 很容易混乱且难以维护。更实际的做法是：
- 在项目根目录写个
build-all.sh（macOS/Linux）或build-all.bat（Windows） - 脚本里逐条调用：
GOOS=linux GOARCH=amd64 go build -o bin/app-linux-amd64 . - 在 GoLand 的 Terminal 标签页里直接运行该脚本，输出清晰、可复现、易调试
- 如果要用 GoLand 的图形化调试功能，只对其中某一个架构单独建 Run Configuration 即可，不必全配
真正容易被忽略的是：GoLand 的 go env 输出始终反映的是宿主机默认值，它不会因 Run Configuration 里的 GOOS 变量而改变——这意味着你在代码里用 runtime.GOOS 拿到的是构建目标平台名，但用 os.Getenv("GOOS") 拿到的才是你手动设置的那个值。别混淆这两者。
