报错“package xxx is not in GOROOT”的根本原因是GO111MODULE=auto默认模式下，Go根据当前目录是否含go.mod或是否在GOPATH/src外自动启用module模式，导致import路径不再按GOPATH/src解析，而是fallback至GOROOT查找；此时若路径不匹配module声明或未正确配置环境变量，即触发该错误。
报错 package xxx is not in GOROOT，根本不是路径写错了，也不是 GOPATH 没配对——而是 Go 的包管理机制在「自动切换模式」时，悄悄绕过了你手写的 src/xxx 路径，转头去 $GOROOT/src 翻标准库了。
GO111MODULE=auto 是默认陷阱
Go 1.11+ 默认启用 GO111MODULE=auto，它不看你的 GOPATH 是否设置、也不管你有没有 go.mod 文件，只凭两个条件决定是否进 module 模式：
- 当前目录下是否存在
go.mod文件 → 有则用 module - 当前目录是否在
$GOPATH/src之外 → 是则强制用 module
这意味着：哪怕你把项目老老实实放在 $GOPATH/src/myproj 下，只要没生成 go.mod，Go 命令仍可能跳过 GOPATH 直接 fallback 到 GOROOT 查找——因为 auto 模式下，go run main.go 这种单文件执行会触发「无模块上下文」逻辑，导致 import 路径被当作绝对路径解析（比如 "mylib" 就真去 $GOROOT/src/mylib 找）。
import 路径 ≠ 文件系统路径（但得匹配 module 名）
你在 $GOPATH/src/foo/bar/baz.go 里写 import "foo/bar"，这行不通。原因有二：
立即学习“go语言免费学习笔记（深入）”；
- 如果启用了 module（
GO111MODULE=on或auto且有go.mod），import 路径必须以go.mod中的module声明为前缀，比如module github.com/user/repo，那你就得写import "github.com/user/repo/bar" - 如果关闭 module（
GO111MODULE=off），import 路径才对应$GOPATH/src下的相对路径，即import "foo/bar"→ 实际找$GOPATH/src/foo/bar
常见翻车点：go mod init myproject 后，go.mod 写的是 module myproject，但你 import 写成 "myproject/bar" —— 这没问题；可如果你 import 写成 "bar" 或 "src/foo/bar"，Go 就会放弃 module 解析，退回到 GOROOT 查找。
GoLand / VS Code 不会自动继承 shell 的 env
你在终端里执行 go env -w GO111MODULE=off，IDE 却依然报错，大概率是因为 IDE 启动时没读取你的 shell 配置（如 ~/.zshrc）。它用的是自己缓存的环境变量快照，或者系统级默认值。
- GoLand：Settings → Go → Build Tags and Vendoring → 把
Go modules integration关掉，或手动在Go Toolchain设置里指定GO111MODULE=off - VS Code：在工作区
.vscode/settings.json加上"go.toolsEnvVars": {"GO111MODULE": "off"} - 验证方式：在 IDE 内置终端运行
go env GO111MODULE，输出必须是off才算生效
真正麻烦的不是怎么关 module，而是关了之后还得确保所有 import 路径都从 $GOPATH/src 开始、所有包目录都在 src 下一层、且不能和标准库重名（比如别建个 src/fmt）。这些约束在 module 模式下反而更松——但代价是必须维护 go.mod 和版本语义。选哪条路，取决于你愿不愿意为历史项目多改几行 import。
