GoLand中真正生效的是Run Configuration里设置的环境变量，它完全覆盖系统变量且不继承IDE设置；项目级配置仅影响语法分析等IDE功能，不参与程序运行。
GoLand 里项目级和模块级环境变量谁生效？
GoLand 不区分“项目级”和“模块级”环境变量的优先级——它压根没有模块级环境变量这个概念。所谓“模块级”，其实是你手动在 Run Configuration 中为某个运行配置（比如一个 go run main.go）单独设置的环境变量，它只影响这一次执行；而“项目级”通常指你在 Settings > Go > GOPATH 或 Settings > Tools > Terminal 里配的全局或终端环境，它们不参与 Go 程序运行时的变量注入。
真正起作用的，只有 Run Configuration 里填的那部分：它完全覆盖系统环境变量，且不继承 GOPATH/GOROOT/GO111MODULE 等任何 IDE 设置的值。哪怕你在 Settings 里把 GO111MODULE=on 设好了，只要 Run Configuration 里没显式写上，程序启动时就可能 fallback 到 auto 模式，导致 go list -m all 报错 not in a module。
如何在 Run Configuration 中正确设置 GO111MODULE 和 GOPROXY
很多人在 Goland 里跑 go run 失败，根本原因不是代码问题，而是 Run Configuration 没配对环境变量。尤其当项目有 go.mod 却提示“module declared but not used”，大概率是 GO111MODULE 没生效。
-
GO111MODULE必须设为on（不是auto），否则在非 GOPATH 路径下会自动禁用模块 -
GOPROXY推荐设为https://goproxy.cn,direct或https://proxy.golang.org,direct，避免因网络问题卡在go mod download - 不要依赖“从 shell 继承环境变量”选项——它不可靠，尤其 Windows 下 PowerShell/CMD 环境变量不互通
- 如果项目需要读取
VIPER的环境变量（比如APP_ENV=prod），也得在这里显式加进去，viper.AutomaticEnv()才能拿到
GOROOT 和 GOPATH 在 Goland 里怎么配才不冲突
Goland 的 Settings > Go > GOROOT 只影响 IDE 自身的语法分析、跳转和工具链调用（比如 go fmt），跟程序运行时的 GOROOT 无关。而 GOPATH 设置在现代 Go 项目中基本无用：只要你启用了模块（GO111MODULE=on），go build 就不会去查 $GOPATH/src。
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
但有两个容易踩的坑：
- 如果你在
Run Configuration里手动写了GOPATH，它会污染go install的输出路径——生成的二进制文件会跑到你指定的$GOPATH/bin，而不是预期的$GOBIN - Goland 默认会把
GOROOT写进PATH，但如果你同时在系统环境变量里也设了GOROOT，且两者指向不同版本（比如 IDE 用 go1.21，终端用 go1.22），就会出现go version和 Goland 提示的版本不一致 - Windows 用户特别注意：
GOROOT值末尾不能带反斜杠（D:\Go\❌），必须是D:\Go✅，否则go env GOROOT可能返回空
为什么改了系统环境变量，Goland 还不认
因为 Goland 启动时就固化了环境变量快照，后续系统里改了 GOBIN 或 GOPROXY，IDE 不会自动 reload。你得重启 Goland，或者更稳妥地——直接在每个 Run Configuration 里显式声明。
另一个常见现象：你在终端里 go env -w GOPROXY=xxx 写入了全局配置，但 Goland 的 Debug 模式仍然走默认代理。这是因为 go env -w 写的是用户级配置，而 Goland 的运行配置默认不加载该层，它只认自己界面里填的值。
最省心的做法：所有影响构建和运行的行为，都收口到 Run Configuration > Environment variables 里统一管理。别指望 IDE 会帮你“智能合并”或“继承”什么，它只认你亲手敲进去的那几行。
