goroot是go安装目录，指向编译器、标准库等路径，与项目无关；gopath在go 1.11+后仅影响旧式依赖存放，项目可放任意位置；go.work自1.18起取代gopath用于多模块管理。
GOROOT 是 Go 安装目录，不是项目目录
GOROOT 指向的是 Go 编译器、标准库、go 命令本身所在的安装路径，比如 /usr/local/go 或 C:\Go。它和你的项目代码完全无关——哪怕你删掉整个 GOPATH（或 go.work），只要 GOROOT 正确，go version、go build 依然能跑。
常见错误现象：go: cannot find main module 或 command not found: go，很多人第一反应是去改 GOROOT，其实往往只是 PATH 没配对，或者压根没装 Go。
- 不要手动设置 GOROOT，除非你装了多个 Go 版本且需要切换（此时用
go install或版本管理工具如gvm更稳妥） - Mac/Linux 下通过
which go找到二进制位置，再用dirname $(dirname $(which go))可推导出默认 GOROOT - Windows 用户注意：安装 MSI 包会自动设 GOROOT；用 ZIP 解压则必须手动加到环境变量，否则
go env GOROOT可能为空或错乱
GOPATH 在 Go 1.11+ 后仅影响老式依赖存放位置
Go 1.11 引入模块（module）机制后，GOPATH 的作用大幅弱化。它现在只管三件事：存放 go get 下来的非模块化包（$GOPATH/src）、编译生成的 $GOPATH/bin 可执行文件、以及 $GOPATH/pkg 中的缓存对象。你自己的项目完全可以放在任意路径，只要根目录有 go.mod 就行。
使用场景：当你用 go get github.com/some/old-repo（该 repo 没声明 go.mod），Go 仍会把它下到 $GOPATH/src/github.com/some/old-repo；但如果你 go get 一个带 module 的包，它会被下载到 $GOMODCACHE（默认在 $GOPATH/pkg/mod），不再碰 src。
立即学习“go语言免费学习笔记（深入）”；
- 不必把项目放
$GOPATH/src下，放桌面、/tmp、甚至 U 盘里都能正常go run main.go - 如果误把项目放
$GOPATH/src/example.com/foo且没go.mod，Go 会按旧 GOPATH 模式构建，可能意外启用 vendor 或忽略replace指令 -
go env GOPATH输出多个路径时（用:或;分隔），只有第一个生效；其余会被忽略，不会合并搜索
go.work 文件正在取代 GOPATH 的多项目管理角色
Go 1.18 加入 go.work，专为同时开发多个 module 项目设计。它不依赖 GOPATH，而是显式列出本地仓库路径，让 go 命令统一识别为“工作区”。这是目前最干净的多项目协作方式。
容易踩的坑：以为 go.work 是全局配置——其实它只对当前目录及子目录生效；父目录的 go.work 不会向上继承，也不会被子目录自动发现。
- 初始化：在空目录运行
go work init，再用go work use ./project-a ./project-b添加路径 - 一旦存在
go.work，go list -m all会显示所有 workspace 内 module，go run也能跨 project 调用本地修改 - 别把
go.work提交到公共仓库——它是开发者本地协作文件，类似.idea，应加进.gitignore
GOROOT 和 GOPATH 都可能被 go env 覆盖，但优先级不同
go env 显示的是最终生效值，但它背后有明确覆盖顺序：命令行参数 > 环境变量 > 默认推导值。比如 GOROOT 若未设环境变量，Go 会从 go 二进制路径反推；而 GOPATH 若未设，则默认为 $HOME/go（Windows 是 %USERPROFILE%\go）。
性能影响很小，但兼容性要注意：某些 CI 脚本硬编码了 $GOPATH/src 路径做 lint 或 test，升级到 Go 1.20+ 后若项目已模块化，这些路径可能根本不存在，导致脚本失败。
- 检查真实值用
go env GOROOT和go env GOPATH，别信文档写的“默认值” - 在 Dockerfile 中，避免写
ENV GOPATH /workspace后又用go mod download——后者不依赖 GOPATH，但前者可能误导后续go install行为 - 跨平台脚本里慎用
$GOPATH/bin：Windows 下实际是%GOPATH%\bin，且路径分隔符不同，直接拼接易出错
真正要盯住的不是这两个变量本身，而是它们是否无意中干扰了模块感知——比如 go list -m 输出异常、go build 忽略 replace、或者 IDE（如 VS Code + Go extension）反复提示“no modules found”，这时候回头查 go env 和当前目录是否有 go.mod 或 go.work，比调 GOROOT/GOPATH 有用得多。
