go modules 开启后 gopath 对依赖管理完全失效，仅影响 go install 的二进制存放路径和 go get 的旧行为；模块模式下依赖查找只认 go.mod 中的 require、replace 和本地相对路径。
Go Modules 开启后 GOPATH 还管用吗
不管用。只要项目根目录下有 go.mod 文件，Go 工具链就强制进入 module 模式，GOPATH 对依赖查找、构建、下载完全失效——它只影响 go install 生成的二进制存放位置（$GOPATH/bin），以及 go get 在无模块时的老行为。
常见错误现象：go build 报错 cannot find module providing package xxx，但明明 $GOPATH/src/xxx 下有代码——这是因为 module 模式下不再扫描 GOPATH/src，只认 replace、require 和本地 ./ 相对路径。
- 模块模式下，
go list -m all显示的是实际解析出的模块版本，和GOPATH无关 -
GOPATH仍会被go install用来决定可执行文件落哪儿，比如go install ./cmd/foo会写入$GOPATH/bin/foo - 如果你在
GOPATH/src里手动改了某个依赖包，又没配replace，module 模式根本不会读它
怎么判断当前项目走的是 GOPATH 还是 Modules
看有没有 go.mod 文件，以及环境变量 GO111MODULE 的值。Go 1.16+ 默认开启 modules，GO111MODULE=on 是常态；只有当项目不在任何 module 内（即找不到 go.mod），且 GO111MODULE=auto 或未设时，才 fallback 到 GOPATH 模式。
使用场景：CI 脚本或多人协作时，有人本地开了 GO111MODULE=off，导致 go.sum 不生成、依赖版本不锁定，上线后行为不一致。
立即学习“go语言免费学习笔记（深入）”；
- 运行
go env GO111MODULE，输出on表示强制模块模式 - 运行
go list -m，成功返回模块名说明已进入 module 模式；报错go: not in a module才是 GOPATH 模式 -
GO111MODULE=off会彻底禁用 modules，哪怕有go.mod也视而不见——这容易引发“本地能跑、CI 报错”的问题
从 GOPATH 迁移到 Modules 时最常踩的坑
不是改个 go mod init 就完事。核心矛盾在于：GOPATH 项目默认把所有代码当成本地路径引用，而 modules 要求显式声明依赖来源与版本。
典型错误现象：迁移后 go run main.go 报 import "xxx" not found，但 xxx 其实是自己写的内部包，只是原来放在 $GOPATH/src/xxx 下。
- 必须用
go mod init example.com/myproject初始化，模块名不能是main或空字符串，否则后续require无法解析相对导入 - 内部包导入路径要改成相对于模块根目录的路径，比如从
import "utils"改成import "example.com/myproject/utils" -
go mod tidy会自动补require，但不会帮你修 import 路径——IDE 重命名功能或gofmt -r可辅助批量改 - 如果项目曾用
vendor，先删掉vendor/目录再go mod tidy，否则可能残留旧依赖干扰解析
GO111MODULE=auto 为什么在某些目录下不生效
因为 auto 的逻辑是：当前路径或任意父目录存在 go.mod 文件 → 启用 modules；否则 → 回退 GOPATH 模式。所以如果你在 $HOME/code/myproj 下执行命令，但 $HOME/go.mod 存在（比如手误创建），整个家目录及子目录都会被识别为 module 根，导致意外行为。
性能影响不大，但兼容性风险高：某些老脚本或 Makefile 假设了 GOPATH 行为，auto 模式下它们可能在某些路径工作，在另一些路径崩溃。
- 检查是否父目录有残留
go.mod：find . -name go.mod -path "./.*" -prune -o -name go.mod -print | head -5 - 临时关闭 modules 测试：在命令前加
GO111MODULE=off go build，确认是否真由模式切换引起 - CI 环境建议显式设
GO111MODULE=on，避免因工作目录不同导致行为漂移
真正麻烦的从来不是开关本身，而是那些藏在 import 路径里、vendor 目录中、或者 CI 配置注释里的隐式假设——它们不会报错，只会等你发版那天突然不 work。
