Go 1.16+ 不需配置 GOPATH，关键要确保 GO111MODULE=on、项目根目录有合法 go.mod，且 VS Code 工作区正确打开该目录；模块路径须为域名格式（如 github.com/user/proj），import 必须与之严格匹配。
Go 1.16+ 不需要配置 GOPATH，也不该去配；真正要确认的是 GO111MODULE 是否为 on，以及项目根目录是否存在合法的 go.mod。
GO111MODULE=off 是最常被忽略的降级陷阱
很多报错（比如 no Go files in current directory、cannot find module providing package）根本不是路径问题，而是模块被意外关闭了。执行 go env GO111MODULE，如果输出是 off 或 auto，就立刻处理：
-
go env -w GO111MODULE=on强制启用模块模式 - 检查
~/.zshrc、~/.bashrc或系统级/etc/profile，删掉任何export GO111MODULE=off - 重启终端或运行
source ~/.zshrc，再验证一次输出是否为on
auto 尤其危险：它会根据当前目录是否有 go.mod 动态切换行为，导致同一命令在不同子目录下结果不一致。
go mod init 的参数不是路径，是模块路径（module path）
写错 go mod init 后面的值，会导致所有 import 语句失效。这不是语法错误，而是模块路径与导入路径不匹配：
立即学习“go语言免费学习笔记（深入）”；
- 错误写法：
go mod init ./mytool→ 模块路径变成./mytool，别人无法go get - 错误写法：
go mod init mytool→ 模块路径是短名，没有域名前缀，发布后别人go get mytool会失败 - 正确写法：
go mod init github.com/yourname/mytool→ 所有import必须以这个前缀开头，如import "github.com/yourname/mytool/config" - 如果项目没远程地址，可用
example.com/myproj占位，但上线前必须替换为真实仓库路径
VS Code 提示 “No modules found” 多半是工作区开错了
这不是环境变量或 GOPATH 问题，而是编辑器没识别到模块根：
- 别用 VS Code 打开整个
~/projects父文件夹；要打开**含go.mod的那一层目录** - 确认
go.mod文件里至少有module example.com/hello和go 1.23两行；缺的话运行go mod tidy补全 - 仍报红线？按
Ctrl+Shift+P→ 输入Go: Restart Language Server，强制重载gopls - 如果
go env GOMOD输出为空或指向错误路径，说明当前目录未被识别为模块根——检查是否误在子目录（如cmd/）里打开了终端
旧 GOPATH 项目迁移时，vendor/ 目录不能直接复用
老项目里的 vendor/ 是 dep、glide 或手动维护的，和 Go Modules 不兼容：
- 迁移前先删掉整个旧
vendor/目录，否则go mod tidy可能读取错误版本 - 运行
go mod vendor生成新vendor/，它只包含go.mod和go.sum锁定的依赖 - CI 中若需离线构建，加
-mod=vendor参数，但本地开发一般不需要保留vendor/ - 如果旧
vendor/里有 patch 或 fork 修改，必须先在go.mod里用replace声明，再跑go mod vendor
模块路径写错、GO111MODULE 状态异常、IDE 工作区没对准 go.mod 所在目录——这三处最容易被跳过，但恰恰是 90% 的“找不到包”“构建失败”问题的根源。
