Go 1.16+默认启用Modules，GOPATH非项目必需，但go install、go get（非模块）等仍依赖它；未设或设错会导致安装失败、路径报错等问题。
Go 1.16 之后默认启用 Go Modules，GOPATH 不再是项目必需项，但只要用到 go get（非模块模式）、go install 全局命令、或某些老工具链（如旧版 gopls、go vet 插件），它依然会被读取；不设或设错会导致 cannot download, $GOPATH not set 或 go install: no install location for directory 这类错误。
为什么 go env GOPATH 返回空或报错
这是最常被误判的信号。Go 1.8+ 默认将 GOPATH 设为 $HOME/go（macOS/Linux）或 %USERPROFILE%\go（Windows），但该值**仅在环境变量未显式设置时由运行时推导**——它不会写入 shell 配置，也不会出现在 env 或 printenv 中。所以：
-
go env GOPATH有输出 ≠ 你已“设置”了它，只是 Go 在用默认值 -
echo $GOPATH为空 ≠GOPATH无效，Go 工具链仍可工作（尤其启用 Modules 后） - 但
go install github.com/xxx/cli@latest会失败，因为该命令**必须写入$GOPATH/bin**，而默认路径若不存在或无写权限，就会报错
设置 GOPATH 的最小必要动作
不需要改 shell 配置文件就能让绝大多数命令跑通，关键是确保三件事同时成立：
-
GOPATH环境变量已导出（哪怕只在当前终端）：export GOPATH="$HOME/go" -
$GOPATH目录存在且可写：mkdir -p "$GOPATH"/{src,pkg,bin} -
$GOPATH/bin已加入PATH：export PATH="$PATH:$GOPATH/bin"（否则go install出的二进制找不到）
这三步做完，再执行 go install github.com/tcnksm/ghr@latest 就能直接在任意目录敲 ghr --help 运行。
立即学习“go语言免费学习笔记（深入）”；
Windows 上 GOPATH 多路径和分号陷阱
Windows 支持用分号分隔多个 GOPATH，比如 GOPATH=D:\go\libs;D:\go\projects，但实际效果有限：
-
go get只往第一个路径的src下存包，后续路径被忽略 -
go install只把二进制写入第一个路径的bin，即使你cd到第二个路径下执行 - 分号后若有空格（如
D:\go\libs; D:\go\projects），整个变量会被截断，go env GOPATH只显示第一段 - 更隐蔽的问题：PowerShell 中用
$env:GOPATH="..."设置时，分号会被当作命令分隔符，必须加引号并转义
结论：Windows 上也建议只设一个 GOPATH，例如 C:\Users\name\go，避免意外行为。
GOROOT 和 GOPATH 绝对不能混用
常见崩溃操作：
- 把
GOPATH设成C:\Go\src（即 GOROOT 的子目录）→go get会尝试往C:\Go\src\src\...写，触发权限拒绝或路径爆炸 - 把
GOPATH和GOROOT设成同一目录 →go build可能覆盖标准库缓存，导致import "fmt"报错 - 在 WSL 中把
GOPATH设为 Windows 路径（如/mnt/c/Users/name/go）→ 文件权限、换行符、符号链接全部异常，go mod tidy偶发卡死
安全做法：GOROOT 留给 Go 安装目录（通常无需手动设），GOPATH 单独选用户主目录下的干净路径，两者物理隔离、无父子关系。
真正容易被忽略的是：即使你全程用 Go Modules，只要执行过一次 go install，就必须保证 $GOPATH/bin 存在且在 PATH 里——这个 bin 目录不是“可选”，而是 Go 工具链硬编码的落点，删掉或权限不对，命令就永远找不到。
