不需要主动设置，Go 1.11+ 默认启用 Modules 模式后 GOPATH 仅用于存放 go install 的二进制（可被 GOBIN 覆盖），依赖解析由 go.mod 和 $GOMODCACHE 决定，不再依赖 GOPATH 路径。
Go 1.11 之后 GOPATH 还需要设置吗？
不需要主动设置，GOPATH 在 Modules 模式下已退居二线。Go 命令默认会忽略 GOPATH（除非显式启用 -mod=vendor 或项目无 go.mod），模块路径由 go.mod 文件和当前目录决定。
常见错误现象：go build 报 cannot find module providing package xxx，但你明明把代码放在 $GOPATH/src/xxx 下——这不是路径不对，而是 Go 已经不按 GOPATH 查包了。
- 只要项目根目录有
go.mod，Go 就进入 Modules 模式，GOPATH不影响依赖解析 -
GOPATH仍会被用于存放go install编译的二进制（默认到$GOPATH/bin），但可被GOBIN覆盖 - 若未设
GOBIN，且$GOPATH/bin不在$PATH中，go install后命令无法直接运行
go mod init 为什么不能在 $GOPATH/src 下自动推导模块名？
因为 Modules 设计上要打破 GOPATH 的路径即导入路径的隐含约定。Go 不再从物理路径“猜”模块路径，而是要求显式声明——哪怕只是临时起个名字。
使用场景：新建项目、迁移老代码、临时实验模块行为。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 执行
go mod init example.com/foo后，所有import必须匹配这个前缀，否则编译报错 - 如果在
$GOPATH/src/github.com/user/repo下执行go mod init，它不会自动填成github.com/user/repo；必须手动指定或加-module参数 - 模块名不是 URL，不需真实存在，但建议与未来可能发布的地址一致，避免后续重命名引发 import 路径变更
还在用 go get 往 $GOPATH/src 放代码？小心依赖混乱
旧式 go get（无 @version）会把代码拉到 $GOPATH/src，但 Modules 模式下它不再更新 go.mod，也不记录版本——等于白装。
常见错误现象：go run main.go 突然失败，提示找不到某个函数，其实是因为本地 $GOPATH/src 里存着一个被覆盖的老版依赖，而 go.mod 记录的是另一版。
- Modules 下应统一用
go get pkg@v1.2.3或go get pkg（自动取 latest tagged 版本），它会写入go.mod并下载到$GOMODCACHE -
$GOMODCACHE默认是$GOPATH/pkg/mod，但它只读，不可手动修改或删子目录——删了会导致下次 build 重新下载 - 想彻底清理缓存？用
go clean -modcache，而不是rm -rf $GOPATH/pkg/mod
交叉编译或 CI 环境里，GOPATH 设不设有什么区别？
几乎没有区别，只要项目带 go.mod 且没显式关 Modules（如 GO111MODULE=off），GOPATH 就只是个摆设。
性能 / 兼容性影响：设了错误的 GOPATH 可能导致 go install 输出二进制到意料之外的位置，但不影响构建本身；CI 中更常见问题是没清 $GOMODCACHE 导致复用脏缓存。
- 推荐 CI 脚本中显式设置
GO111MODULE=on，避免因 Go 版本或工作目录位置触发自动降级 - 不要 export
GOPATH到非必要路径（比如/tmp），某些老工具链（如 dep、旧版 gopls）可能误读它 - Go 1.19+ 已默认开启 Modules，
GO111MODULE环境变量基本可弃用，但 CI 中留着更稳妥
真正容易被忽略的是 go.work 文件的存在——它会覆盖单个模块的 go.mod 行为，形成多模块工作区。这种情况下，GOPATH 更无关紧要，但路径解析逻辑会变复杂，调试时得先确认有没有 go.work。
