Go Modules 开启后 GOPATH 还管用吗
不管用。只要项目根目录下有 go.mod 文件，go 命令就进入 module 模式，完全绕过 GOPATH/src 的路径查找逻辑。这时候把代码放在 $GOPATH/src/github.com/user/repo 里，go build 也不会自动识别它为本地依赖——除非你显式用 replace 或 require 声明。
常见错误现象：go get github.com/some/lib 下载到了 $GOPATH/pkg/mod，但自己写的同名本地包（比如也在 $GOPATH/src/github.com/some/lib）却始终不被引用；或者 go run main.go 报错 cannot find module providing package，其实只是因为没在 module 根目录下执行。
- 判断是否在 module 模式：运行
go env GO111MODULE，输出on或auto（且当前目录含go.mod）即生效 -
GOPATH在 module 模式下仅用于存放下载的依赖缓存（$GOPATH/pkg/mod）和编译产出（$GOPATH/bin），不再决定源码位置 - 如果误把 module 项目放在
$GOPATH/src下并期望“自动识别”，反而容易因路径冗余引发import path conflicts
迁移旧 GOPATH 项目到 Go Modules 的关键三步
不是删掉 GOPATH 环境变量，而是让项目主动声明 module 身份，并理清依赖来源。旧项目往往依赖 $GOPATH/src 下的本地修改，直接 go mod init 会丢失这部分关联。
- 在项目根目录运行
go mod init example.com/myapp（模块名建议用实际域名或唯一标识，别用main） - 立即执行
go mod tidy—— 它会扫描.go文件里的import，自动写入require并下载对应版本；若本地有未发布改动，需紧接着用replace指向本地路径，例如：replace github.com/old/lib => ../local-lib
- 检查
go.sum是否生成、go list -m all输出是否包含所有预期依赖；特别注意私有仓库（如 GitLab 内网地址），可能需要配置GOINSECURE或git config凭据
GO111MODULE=off 时为什么 import 本地 GOPATH 包仍失败
即使关了 module 模式，go 命令仍要求 import 路径与磁盘物理路径严格一致。比如你在 $GOPATH/src/github.com/user/tool 下写代码，import "github.com/user/tool/sub" 才合法；若写成 import "tool/sub" 或 import "./sub"，直接报错 import path does not begin with hostname。
立即学习“go语言免费学习笔记（深入）”；
性能影响很小，但兼容性陷阱明显：很多老教程教人把项目放 $GOPATH/src 就能“免配置”，结果遇到大小写不一致（GitHub.com vs github.com）、路径含空格、Windows 驱动器字母大小写等问题，go build 就静默失败。
- 确认
GOPATH值是否真实包含你的源码目录（echo $GOPATH/go env GOPATH） - 检查
import语句中的路径是否精确匹配$GOPATH/src/后的相对路径（区分大小写、无前导./） - 避免在
$GOPATH/src外写代码还幻想被识别——GO111MODULE=off不等于“任意路径都能 import”
CI/CD 中 GOPATH 与 Go Modules 混用的典型翻车点
流水线脚本里同时出现 export GOPATH=/tmp/gopath 和 go mod download，看似无害，实则埋雷。问题不在命令本身，而在于不同 Go 版本对 GO111MODULE 默认值的处理差异：Go 1.12+ 默认 auto，但某些旧版 CI 镜像可能仍是 off；一旦环境变量没传透，go build 就退回到 GOPATH 模式，导致依赖版本错乱或找不到包。
- CI 脚本开头强制声明：
export GO111MODULE=on（不要依赖auto） - 避免在构建步骤中修改
GOPATH——go mod不需要它，改了反而干扰$GOPATH/pkg/mod缓存位置 - 私有模块拉取失败时，优先查
go env GONOPROXY是否漏配，而不是怀疑GOPATH设置不对
真正麻烦的从来不是 GOPATH 该不该删，而是哪些地方隐式依赖了它的路径规则，又没在 go.mod 里补全声明。这类问题往往只在跨机器、换 Go 版本、进 CI 时突然暴露。
