GoLand中GOPATH是项目级配置而非系统环境变量，不勾选“Use GOPATH from system environment”时，IDE忽略终端$GOPATH，仅使用Settings→Go→GOPATH中手动指定的路径（需含src/pkg/bin），该路径决定go get下载位置、go install输出目录及包搜索路径；GOROOT则独立控制SDK版本，两者职责分离。
GoLand里改GOPATH不是改环境变量，而是覆盖项目级设置
GoLand默认不读系统GOPATH环境变量，它用自己的配置项控制项目行为。你在终端里echo $GOPATH看到的值，和IDE里实际用的可能完全不一样。这个差异是多数人遇到“包找不到”或“go install生成的命令在IDE里跑不了”的根源。
修改位置在 Settings → Go → GOPATH（macOS 是 Preferences → Go → GOPATH）。这里填的路径会直接用于：go get下载位置、go build时的包搜索路径、以及go install生成二进制的存放目录（即$GOPATH/bin）。
- 勾选 Use GOPATH from system environment 才会让IDE读取你shell里设的
GOPATH；不勾选就是强制使用下面手动填的路径 - 支持多个路径，用英文冒号（Linux/macOS）或分号（Windows）分隔，但第一个路径始终是主工作区，
go get默认只往第一个里下代码 - 路径必须包含
src、pkg、bin三个子目录，否则IDE会报错或静默忽略
GOROOT和GOPATH在GoLand里是两个独立开关
很多人以为改了GOPATH就得同步调GOROOT，其实完全没必要。两者职责清晰：GOROOT只管Go编译器和标准库在哪，GOPATH只管你的代码和第三方包放哪。GoLand允许你为不同项目配不同GOROOT（比如一个用1.21，一个用1.23），但GOPATH一般全局统一更省事。
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
-
GOROOT路径必须指向完整安装目录（含bin/go、src、pkg），不能只指到bin下 - 如果你用
asdf或gvm管理Go版本，GoLand能自动识别已注册的SDK，不用手动填路径 - 改完
GOROOT后，记得点右下角的 Reload project，否则旧编译器缓存还在生效
Go Modules开启后，GOPATH只影响工具安装，不影响依赖管理
只要项目根目录有go.mod，且GO111MODULE=on（Go 1.16+ 默认开启），GoLand就完全绕过GOPATH/src找依赖——它只看go.mod和$GOMODCACHE（默认在$GOPATH/pkg/mod）。这时候你改GOPATH，对go run、go test几乎没影响，但会影响这些事：
-
go install装的CLI工具（如gofumpt、stringer）会落到$GOPATH/bin，所以PATH里必须包含它才能在终端调用 - 某些老插件或自定义脚本仍硬编码
$GOPATH/src路径，比如手动go build某个本地包时显式写import "myproj/utils" - IDE的“Go to Declaration”跳转，在非Module项目里严重依赖
GOPATH/src结构
容易被忽略的Windows路径分隔符和权限问题
Windows用户在GoLand里填GOPATH时，常犯两个低级但致命的错：一是路径末尾加了反斜杠（C:go），二是路径含空格或中文。前者会导致go mod download失败并报invalid version，后者会让go install生成的exe无法执行。
- 路径一律用正斜杠或双反斜杠：
C:/Users/name/go或C:\Users\name\go，别用C:Users amego - 如果
GOPATH设在C:Users下，确保当前用户对bin和pkg目录有完全控制权限（右键→属性→安全→编辑） - 改完设置后，务必在Terminal里运行
go env GOPATH确认输出和IDE里填的一致；如果不一致，说明没勾选“Use GOPATH from system environment”，且IDE配置未生效
GOPATH真正关键的时刻往往不在编码时，而在你把别人写的工具链（比如用go install装的linter）集成进CI或分享给同事时——路径错一丁点，整个流程就卡住。 
