go 1.11+项目完全不需要gopath管理依赖，硬设反而干扰go mod；启用go111module=on后，命令只认go.mod和pkg/mod缓存，不扫描gopath/src。
Go 1.11+ 项目完全不需要 GOPATH 来管理依赖，硬设 GOPATH 反而容易干扰 go mod 行为。
go mod 启用后 GOPATH 不再参与依赖解析
启用 GO111MODULE=on（Go 1.16+ 默认开启）后，go build、go run、go get 等命令会忽略 GOPATH/src 中的包，只认当前模块根目录下的 go.mod 和 GOPATH/pkg/mod 缓存。即使你把依赖代码手动扔进 $GOPATH/src/github.com/foo/bar，只要没在 go.mod 里声明，就不会被加载。
常见错误现象：
- 明明
$GOPATH/src下有某包，go build却报cannot find package - 执行
go get github.com/foo/bar没反应，或提示go: downloading github.com/foo/bar v1.2.3但没写进go.mod
根本原因：模块模式下，go get 不再往 $GOPATH/src 写代码，而是下载到 $GOPATH/pkg/mod 并更新 go.mod；go build 查找依赖时，只看 go.mod 声明 + pkg/mod 缓存，不扫描 src。
GOROOT 和 GOPATH 都不该和模块路径冲突
模块路径（module 指令值）必须是全局唯一的导入路径，比如 github.com/yourname/project。如果误把项目放在 $GOPATH/src 下并直接用该路径初始化模块，会导致两个问题：
-
go mod init时若路径含空格、中文或非法字符，生成的模块名会被转义（如my project→my_project），后续 import 语句必须严格匹配 - 若模块名和本地
$GOPATH/src路径不一致（例如项目在/tmp/myapp，却go mod init github.com/xxx/oldrepo），go list -m all会显示replace或indirect异常
正确做法：项目可放在任意目录（包括桌面、/tmp、甚至 ~/projects），运行 go mod init github.com/yourname/project 显式指定模块名，之后所有 import 都按这个路径写 —— 它和物理路径无关。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
GO111MODULE=auto 时的隐性陷阱
默认 GO111MODULE=auto 的行为是：当前目录或父目录存在 go.mod 就启用模块模式，否则退回到 GOPATH 模式。这导致很多“看似正常”的旧项目在新环境出问题：
- 在
$GOPATH/src外新建项目，没手动go mod init，go get会静默失败（不报错但不写go.mod） - 项目根目录有
go.mod，但某个子目录被误当成工作目录执行go build，因该子目录无go.mod，触发 GOPATH 模式，找不到依赖 -
go env GOPATH显示路径，让人误以为还在用 GOPATH，其实只是模块缓存和工具安装位置
建议始终显式设置：export GO111MODULE=on，避免自动切换带来的不确定性。检查是否生效：运行 go env GO111MODULE，输出必须是 on。
vendor 目录与 GOPATH 的残留依赖
启用 go mod vendor 后生成的 vendor 目录，是模块依赖的快照副本，不再依赖 GOPATH 结构。但要注意：
-
go build -mod=vendor会强制只读vendor，此时GOPATH完全无关 —— 即使 unset GOPATH 也能构建成功 - 如果项目同时存在
vendor和go.mod，且go build没加-mod=vendor，仍走模块模式，vendor被忽略 -
go mod vendor不会复制replace指向的本地路径依赖（如replace example.com/a => ../a），这些依赖必须真实存在且可访问
真正需要 GOPATH 的只剩少数场景：安装 CLI 工具（go install）、运行 gopls 或 dlv 等二进制，它们默认装到 $GOPATH/bin；但现代做法更推荐用 go install some/tool@latest，它会自动识别 GOBIN 或 fallback 到 $GOPATH/bin。
最易被忽略的一点：模块模式下 GOPATH 的唯一作用是存放 pkg/mod 缓存和 bin 工具，它和你的项目源码、依赖版本、构建结果都无直接关系。盯着 GOPATH/src 看依赖，就像翻旧硬盘找 Git 提交记录 —— 方向就错了。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
