GoLand中跨平台编译需显式配置GOOS、GOARCH和CGO_ENABLED=0，否则默认使用Windows环境变量导致失败；多平台可复制运行配置并分别设置环境变量，缓存自动按目标平台分离。
在 Windows 上用 GoLand 生成 Linux 或 macOS 可执行文件，根本不需要虚拟机或 Docker —— 关键是让 GOOS 和 GOARCH 环境变量真正生效，且避开 CGO_ENABLED=1 这个默认陷阱。
为什么 go build 能跨平台，但 Goland 里点“Run”却不行
Goland 的 “Run” 或 “Build” 按钮默认走的是当前系统环境（即 GOOS=windows），它不会自动读取你设在终端里的环境变量。IDE 自己维护了一套构建上下文，必须显式配置。
- 检查当前项目运行配置：右上角下拉菜单 → “Edit Configurations…” → 找到你的
go build配置 → 展开 “Environment variables” - 必须手动添加：
GOOS=linux（或darwin）、GOARCH=amd64（或arm64） - 务必同时加上：
CGO_ENABLED=0—— 否则即使设置了GOOS，Go 仍会尝试调用本地 Windows 的 gcc，导致编译失败或生成带动态链接的非可移植二进制 - 如果项目里用了
cgo（比如调了 SQLite、OpenSSL），那这个设置会让构建直接报错；此时得先确认是否真需要跨平台支持 cgo —— 大多数 CLI 工具和 HTTP 服务都不需要
如何让 Goland 一键切换多个目标平台
不用反复改配置，Goland 支持“复制配置 + 改环境变量”，适合多平台交付场景。
GoLand 2026.1.1
下载
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
- 在 “Edit Configurations…” 里，选中已有配置 → 点左上角 “+” → “Copy Configuration”
- 新配置重命名为
build-linux-amd64，修改 Environment variables 为：GOOS=linux;GOARCH=amd64;CGO_ENABLED=0 - 再复制一份叫
build-darwin-arm64，对应GOOS=darwin;GOARCH=arm64;CGO_ENABLED=0 - 每份配置的 “Output directory” 建议设为不同子目录（如
./dist/linux），避免覆盖 - 执行时直接从右上角选择对应配置，点 ▶ 即可 —— 不用开终端、不依赖 shell 脚本
编译缓存对交叉编译是否有效
有效，但有前提：缓存键（cache key）包含 GOOS 和 GOARCH。也就是说，GOOS=linux 下编译过的包，不会复用 GOOS=windows 的缓存结果。
- 只要没手动清空
GOCACHE（默认是%LocalAppData%\GoBuildCache），每次跨平台构建都会复用已编译的目标平台标准库对象 - 首次构建某个新组合（如
GOOS=linux GOARCH=arm64）会稍慢，后续就快得多 - 如果你发现多次构建速度没变化，检查是否误设了
GOCACHE=off，或在配置里勾选了 “Clear cache before build”（这个选项在 Goland 的 Run Configuration 里默认不勾选，但有人会手抖打开） -
CGO_ENABLED=0也参与缓存键计算 —— 所以开启/关闭 cgo 会产生完全不同的缓存路径，互不干扰
生成的二进制为什么在目标机器上 still fails with “no such file or directory”
这不是 Go 编译问题，而是你漏掉了最关键的验证步骤：静态链接是否真的完整。
- 在 Windows 上用
GOOS=linux CGO_ENABLED=0 go build生成的文件，用file ./myapp（在 WSL 或 Linux 上运行）检查，输出必须含statically linked；如果出现dynamically linked，说明CGO_ENABLED没生效，或者某处隐式启用了 cgo（比如依赖了net包且netgo构建标签被绕过） - 常见坑：某些第三方包（如
github.com/mattn/go-sqlite3）强制依赖 cgo，哪怕你设了CGO_ENABLED=0，也会触发构建失败；这时要么换纯 Go 实现（如github.com/ziutek/mymysql），要么接受无法交叉编译 - 另一个隐形依赖是
os/user或net/http在某些GOOS下会回退到 cgo 实现 —— 最稳妥方式是构建后用ldd ./myapp（Linux）或otool -L ./myapp（macOS）确认无外部 so/dylib 引用
交叉编译不是“设了变量就完事”，真正的难点在于 cgo 的边界控制和构建产物的可移植性验证 —— 这两步跳过，90% 的失败都发生在这儿。
