即使启用GO111MODULE=on，GOPATH仍影响go install输出位置、go get工具安装路径、IDE/gopls缓存、go list非module包查找及go test -i依赖缓存。
Go 1.11 之后，GOPATH 已不再是必须配置的环境变量——模块（module）模式下，项目可脱离 GOPATH 目录结构独立存在。但很多旧项目、CI 脚本、工具链（如 go get 安装命令行工具）仍会读取或依赖 GOPATH，不设它可能触发 cannot find package 或 GOBIN is not set 类错误。
为什么现在还要关心 GOPATH？
即使启用 GO111MODULE=on，以下场景仍绕不开 GOPATH：
-
go install编译后的二进制默认写入$GOPATH/bin，除非显式设置GOBIN - 用
go get -u升级工具（如golangci-lint、dlv）时，若未设GOPATH，会 fallback 到$HOME/go，但部分 shell 或容器环境可能没这个目录 - 某些 IDE（如旧版 Goland）或
gopls的缓存路径仍参考GOPATH - 运行
go list -f '{{.Dir}}' some/import/path时，若包不在 module 中，会去GOPATH/src查找
如何安全地设置 GOPATH（推荐值与位置）
不要强行复用旧习惯把 GOPATH 设为 ~/go 并往里塞代码；更稳妥的做法是「分离用途」：
-
GOPATH=$HOME/go—— 保持默认，只用于存放第三方工具和go get下载的包源码（即src和bin），不放自己的项目 - 自己的项目放在任意路径（如
~/projects/myapp），用go mod init初始化 module，完全独立于GOPATH - 如需控制二进制输出位置，优先设
GOBIN=$HOME/bin（并确保该目录在$PATH中），而非依赖$GOPATH/bin
验证是否生效：go env GOPATH 应输出你设定的路径；go env GOBIN 若为空，则实际使用的是 $GOPATH/bin。
立即学习“go语言免费学习笔记（深入）”；
常见错误：GOPATH 包含空格或符号链接路径
Go 工具链对路径中的空格、波浪线（~）、软链接处理不稳定，尤其在 Windows 和 macOS 上易出问题：
- 错误写法：
GOPATH=~/go（shell 展开可能失败，go env显示字面量~/go） - 错误写法：
GOPATH=/Users/me/go symlinked（含空格） - 错误写法：
GOPATH=/opt/go（指向挂载点或 NFS 路径，go build可能卡住或报permission denied） - 正确做法：始终用绝对路径，且确保目录存在、可读写：
mkdir -p $HOME/go/{bin,src,pkg}，然后export GOPATH=$HOME/go
GO111MODULE=on 时 GOPATH 还影响什么？
开启模块模式后，GOPATH 对「构建依赖」几乎无影响（依赖走 go.mod + pkg/mod），但它仍决定：
-
go install的输出位置（除非设了GOBIN） -
go list -m all中本地 replace 路径是否被识别（若 replace 指向$GOPATH/src/xxx，则需确保该路径存在且是 module 根） -
go clean -modcache不动GOPATH，但go clean -cache会清理$GOCACHE（另一独立变量）
真正容易被忽略的是：GOPATH 会影响 go test -i 缓存的安装位置——它仍会把测试依赖编译到 $GOPATH/pkg 下，哪怕项目本身是 module。这点在离线 CI 环境中可能导致意外缺失。
