goland项目级环境变量需在file→settings→go→go environment→environment右侧“…”中配置，仅对当前项目生效，可隔离go111module、gobin、goproxy等变量，避免多项目冲突。
GoLand 不同项目必须用项目级环境变量隔离，全局环境变量（如系统 PATH 或用户变量）无法区分项目需求；否则会触发 go mod 冲突、GOBIN 混乱、甚至 go run 找不到依赖。
GoLand 项目级环境变量在哪配
不是改系统变量，也不是在终端里 export，而是进 IDE 设置里单独绑定到项目：
- 打开项目后，点击顶部菜单 File → Settings（Windows/Linux）或 GoLand → Preferences（macOS）
- 左侧导航选 Go → Go Environment
- 在 Environment 字段右侧点
…，打开环境变量编辑窗口 - 在这里添加/修改变量，比如
GO111MODULE=on、GOBIN=$GOPATH/bin、GOPROXY=https://goproxy.cn
这个配置只对当前项目生效，切换项目时自动切换环境变量上下文。
为什么不能只靠系统 GOPATH/GOROOT
系统级 GOROOT 可以共用（指向同一套 Go 安装），但 GO111MODULE、GOBIN、GOPROXY 这些变量一旦全局设死，就会导致：
GoLand 2026.1.1
下载
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
- 老项目（无
go.mod）被强制走模块模式，报错go: modules disabled - 新项目用了私有代理，但老项目需要直连 internal repo，全局
GOPROXY会堵死后者 -
go install输出路径被GOBIN锁死，多个项目生成的二进制互相覆盖
项目级环境变量能绕过这些冲突，尤其适合混合维护 legacy + module 项目的团队。
GOBIN 和 GOPATH 在项目配置里怎么写才不踩坑
关键不是“设不设”，而是“路径是否可预测、是否隔离”：
- 不要留空
GOBIN：默认会落到$GOROOT/bin，污染 SDK 目录；显式设为$GOPATH/bin或更安全的$PROJECT_DIR/out/bin -
GOBIN路径里别用硬编码（如D:\myproj\bin），优先用 GoLand 内置变量：$PROJECT_DIR、$GOPATH、$GOROOT - 如果项目用模块（有
go.mod），GOBIN的值不影响go run，但会影响go install输出位置——这点常被忽略 -
GOROOT一般不需要在项目级重设，除非你真在单机跑多个 Go 版本（比如 1.21 和 1.23），此时才在项目环境变量里覆盖它
多项目同时开时，环境变量会串吗
不会。GoLand 每个窗口（或每个独立项目标签页）加载的是各自配置的环境变量，和系统变量完全解耦。但要注意一个细节：
- 如果你用
Terminal标签页跑命令，默认继承的是系统环境变量，不是项目级设置 —— 想让它同步，得在 Settings → Tools → Terminal → Shell path 里勾选 Activate environment variables from project configuration - Run/Debug 配置里的
Environment variables是另一层覆盖，优先级高于项目级 Go Environment，适合临时调试用
真正容易出问题的不是“会不会串”，而是忘了 Terminal 默认不读项目变量 —— 导致你在 IDE 里能跑通，命令行里却报 cannot find module。
