go111module=off时，go工具强制使用gopath模式，项目必须位于gopath/src下才能被识别，依赖从gopath/src和vendor查找，go mod命令失效且无法管理模块。
GO111MODULE=off 时 GOPATH 是项目路径的硬性入口
当 GO111MODULE=off（或未设置、Go 版本 GOPATH 定位源码。它不是可选配置，而是构建逻辑的起点——go build、go install、go test 全部从 $GOPATH/src 开始解析导入路径。
常见错误现象：can't load package: package .: no Go files in /path/to/your/project，往往是因为项目没放在 $GOPATH/src/github.com/username/repo 这类符合导入路径的子目录下。
-
GOPATH必须是绝对路径，不能含符号链接（某些 macOS/Linux 环境下软链会导致go list失败） - 多个
GOPATH（用:分隔）会按顺序查找，但go get只写入第一个路径的src -
go install生成的二进制文件一定落到$GOPATH/bin，且必须把该目录加入PATH才能直接运行
GO111MODULE=on 后 GOPATH 仅用于存放全局工具和缓存
启用模块模式后，GOPATH 不再参与项目代码定位——你的项目可以放在 /tmp/hello 或 D:\projects\api 任意位置，只要根目录有 go.mod。
但它仍被 Go 工具链用于两件事：go install 安装的命令行工具（如 gofumpt、stringer）默认输出到 $GOPATH/bin；go mod download 下载的包缓存（$GOPATH/pkg/mod）也仍在原处。
- 如果你只用
go run main.go且不go install任何工具，GOPATH实际上可以不设（Go 1.16+ 会 fallback 到$HOME/go） -
$GOPATH/pkg/mod是共享缓存，不同项目共用同一份依赖包，删掉会触发重新下载，但不会影响go.mod版本声明 -
GOBIN环境变量可覆盖$GOPATH/bin，适合多版本工具隔离场景
GOROOT 和 GOPATH 容易混淆的边界
GOROOT 是 Go 编译器和标准库所在位置，由安装过程决定；GOPATH 是你写代码、装依赖、放二进制的地方——二者绝不重叠，也不能互相替代。
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
典型误配：GOPATH 被设成 /usr/local/go（即 GOROOT 路径），会导致 go get 尝试往标准库目录写第三方包，权限失败或污染系统安装。
-
go env GOROOT输出应为/usr/local/go（Linux/macOS）或C:\Go（Windows），而go env GOPATH应指向用户目录下的独立路径（如$HOME/go） - 修改
GOPATH后务必重启 shell 或 source 配置文件，否则go env显示旧值 -
GOROOT几乎从不需要手动设置，除非你手动解压多个 Go 版本并切换使用
新项目到底要不要管 GOPATH？
答案很直接：不用主动管理，但得知道它在哪、在干什么。
现代 Go 开发中，你只需在项目根目录执行 go mod init example.com/myapp，之后所有依赖、构建、测试都围绕 go.mod 展开。GOPATH 退化为后台缓存和工具安装目录，就像浏览器的磁盘缓存——你不需要天天清理，但得明白它存在且可能占几个 GB 空间。
真正容易被忽略的是：$GOPATH/pkg/mod 目录权限问题（尤其 Docker 构建时以 root 写入，宿主机非 root 用户无法删除）；以及 CI 环境里未清理 $GOPATH/pkg/mod 导致依赖缓存过期却没报错。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
