GO111MODULE=on 时 GOPATH 几乎无用，仅 go install 默认输出到 $GOPATH/bin、旧项目 go get 及部分 IDE 仍依赖它；GOROOT 不该手动设置，应由 Go 自动推导，否则易致标准库找不到或交叉编译失败。
Go 程序不依赖 GOPATH 或 GOROOT 环境变量来运行，但构建、模块解析和工具链行为会受它们影响；现代 Go（1.11+）默认启用 GO111MODULE=on，此时 GOPATH 对依赖管理已基本失效。
GO111MODULE=on 时，GOPATH 还有用吗？
几乎没用。模块模式下，go build、go run 直接读取 go.mod，不再查 GOPATH/src。但以下场景仍会触碰 GOPATH：
-
go install编译命令行工具时，默认把二进制写入$GOPATH/bin（除非显式设了GOBIN） -
go get在旧项目（无go.mod）中仍可能拉包到$GOPATH/src - 某些 IDE（如老版本 VS Code Go 插件）或脚本仍硬编码引用
GOPATH
所以：不是“不能删”，而是“删了可能让 go install 输出找不到，或导致某些工具报 cannot find module providing package”。
为什么 GOROOT 通常不该手动设置？
Go 安装器（如 apt、brew、官方二进制包）会把 GOROOT 写进启动脚本，或由 go 命令自己推导。手动设错会导致：
立即学习“go语言免费学习笔记（深入）”；
-
go命令找不到标准库，报cannot find package "fmt"等错误 - 交叉编译失败，因为
GOROOT/src/runtime路径不对 -
go env GOROOT和实际路径不一致，go tool子命令异常
验证方式很简单：go env GOROOT 输出的路径，必须存在 src/fmt 和 pkg/tool 子目录。如果不确定，干脆别设 —— go 自己找得比人准。
GOBIN 和 $PATH 配合的实操要点
想让 go install 生成的命令全局可用，关键不是改 GOPATH，而是控制输出位置 + 确保在 PATH 中：
- 设
GOBIN=/usr/local/go-bin（或任何你有写权限的目录），避免污染$GOPATH/bin - 把该路径加进
PATH：比如在~/.zshrc里加export PATH="/usr/local/go-bin:$PATH" - 注意顺序：
GOBIN路径必须在PATH中靠前，否则系统自带同名命令（如swagger）会优先被调用 - 执行
go install golang.org/x/tools/cmd/goimports@latest后，直接敲goimports就能用
常见坑：GOBIN 路径没写进 PATH，或写了但 shell 没重载配置，结果提示 command not found。
多版本 Go 共存时，环境变量怎么管？
用 goenv 或 asdf 管理版本，它们本质是动态切换 GOROOT 和 PATH 中的 go 二进制路径。此时：
- 不要手动 export
GOROOT，交给版本管理工具控制 -
GO111MODULE建议始终设为on，避免不同 Go 版本因模块开关不一致导致构建行为突变 - 检查
go env输出里的GOPATH是否是你预期的用户目录（如/home/you/go），不是根目录或临时路径
最容易被忽略的一点：GO111MODULE 的值在 shell 子进程中可能继承父进程，但某些 CI 环境（如 GitHub Actions 的 setup-go）会显式覆盖它 —— 如果本地正常、CI 报 no required module provides package，先看这个。
