完全不影响。GO111MODULE=on 时，Go 工具链强制进入模块模式，依赖查找仅依据 go.mod 中的 require、replace 和本地相对路径，完全忽略 GOPATH/src；GOPATH 仅影响 go install 的二进制输出路径（$GOPATH/bin）。
GO111MODULE=on 时 GOPATH 还会影响依赖吗
完全不影响。只要项目目录下有 go.mod，Go 就只认 require、replace 和本地相对路径（如 ./internal），GOPATH/src 下的代码哪怕存在也不会被加载。
常见错误现象：go build 报 cannot find module providing package xxx，但你明明在 $GOPATH/src/github.com/user/lib 放了代码——这是因为模块模式下根本不会扫描 GOPATH/src。
-
go list -m成功返回模块名，说明已进 module 模式；报错go: not in a module才是 GOPATH 模式 -
go env GO111MODULE输出on是当前标准行为，off会强制禁用 modules，哪怕有go.mod也无视 -
go install ./cmd/foo仍会把二进制写入$GOPATH/bin，这是唯一还受 GOPATH 影响的地方
多个 Go 版本共存时如何避免 GOROOT 冲突
直接替换系统 Go 安装路径（如 /usr/local/go）必然导致混乱，尤其 CI 脚本或同事本地环境不一致时。
正确做法是用版本管理工具隔离 GOROOT，而不是靠环境变量硬切：
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- macOS 推荐
g（brew install g），执行g install 1.21.0后用g use 1.21.0切换，它改的是软链接而非全局 PATH - Linux 可解压多个 Go 版本到独立目录（如
/opt/go/1.20、/opt/go/1.21），再用export GOROOT=/opt/go/1.21显式指定 - 切换后必须运行
go clean -cache -modcache，否则旧版本缓存可能干扰新版本构建
模块路径和本地目录名不一致引发的包名冲突
Go 不检查 import 路径，只认 package xxx 声明。如果目录叫 authz/ 但文件里写 package auth，go test ./authz 会失败，而 go build 可能侥幸通过——这是典型的隐性故障。
工具链（VS Code、go list、go vet）都期望目录名与包声明严格一致：
- 目录名
logger/→ 包声明必须是package logger，全小写、无下划线、无驼峰 -
go mod tidy不会报这个错，它只管依赖路径，不管包内声明是否匹配目录名 - 一旦不一致，IDE 提示“未解析导入”、测试文件找不到包、
go list -f '{{.Dir}}' ./authz返回空——这些才是真实信号
第三方包同名但路径不同，编译报 “redeclared in this block” 怎么办
这不是 bug，是 Go 的显式设计：编译器认的是包名（package http2），不是 import 路径。只要两个包都声明了同名 package http2，就构成冲突。
必须用 import 别名区分，且别名要出现在所有引用之前：
- 写法
http2x "golang.org/x/net/http2"最安全，调用时明确为http2x.ConfigureTransport() - 别名不能是 Go 关键字（如
type），也不能和当前文件已声明的变量名重复 - 不要以为“我只用其中一个的函数”就能绕过——只要 import 了同名包，就触发冲突，哪怕一行调用都没有
模块路径变更（比如从 v1 升级到 v2）时，别名可以保持不变，但要注意 API 是否兼容——别名掩盖不了字段删除或方法签名变化。
