Go 1.16后GOROOT通常自动识别，GOPATH在启用modules后非强制但仍有用：GOROOT指向Go安装根目录，误设易致工具链异常；GOPATH默认$HOME/go，影响go install输出、旧项目结构及部分工具，建议保留默认并确保$GOPATH/bin在PATH中。
Go 1.16 之后，GOROOT 通常无需手动配置，而 GOPATH 在启用 Go modules 后也不再强制要求——但理解它们的作用和正确设置，对调试、跨环境开发、自定义构建或维护旧项目仍很关键。
GOROOT：指向 Go 安装目录，多数情况自动识别
GOROOT 是 Go 工具链（如 go 命令、编译器、标准库）的根目录。官方安装包或通过 apt/brew 安装时，它通常被设为默认路径（如 /usr/local/go 或 /opt/homebrew/Cellar/go/1.22.0/libexec）。
验证当前值：
go env GOROOT
除非你手动解压多个 Go 版本并切换使用（例如用 gvm 或软链接管理），否则不建议显式设置 GOROOT。误设可能导致 go 命令找不到标准库或内部工具。
立即学习“go语言免费学习笔记（深入）”；
- 多版本共存时，可通过修改
PATH切换不同go可执行文件，让其自动推导对应GOROOT - 若必须手动指定（如从源码编译安装），在 shell 配置中添加：
export GOROOT=$HOME/go-src（路径需真实存在且含src、bin等子目录） - 运行
go env -w GOROOT=...不推荐——这会写入全局配置，可能干扰其他 Go 版本
GOPATH：模块时代下仍影响本地工具与传统工作流
GOPATH 默认是 $HOME/go，它曾是 Go 1.11 之前唯一指定代码、依赖和编译产物存放的位置。启用 modules（go mod init 后）后，项目依赖不再存于 $GOPATH/src，但以下场景仍依赖 GOPATH：
-
go install编译的可执行文件默认输出到$GOPATH/bin（该目录需加入PATH才能直接运行命令） - 未启用 modules 的旧项目仍按
$GOPATH/src/github.com/user/repo结构组织代码 - 某些工具（如
gopls、goimports）在非 module 模式下会回退查找GOPATH
推荐做法：
- 保留默认
GOPATH（无需显式设置），确保$GOPATH/bin在PATH中：export PATH="$PATH:$GOPATH/bin" - 若想统一管理多个工作区（比如区分个人项目、公司项目），可单独设置：
export GOPATH=$HOME/dev/go-personal，并配好对应PATH - 避免将
GOPATH设为项目目录本身——这会破坏模块语义，导致go list或go build行为异常
现代工作流：优先用 modules，弱化 GOPATH 依赖
新建项目时，直接在项目根目录运行：
go mod init example.com/myapp
此后所有依赖下载到 ./vendor（如启用 vendor）或缓存到 $GOCACHE（默认 $HOME/Library/Caches/go-build 或 $HOME/.cache/go-build），不再触碰 GOPATH/src。
关键配置建议：
- 确认
GO111MODULE为on（Go 1.16+ 默认开启），避免意外进入 GOPATH 模式 - 用
go install example.com/cmd/tool@latest安装远程命令行工具，它会自动下载并放入$GOPATH/bin - 查看当前环境摘要：
go env—— 关注GOPATH、GOROOT、GO111MODULE、GOCACHE四项
常见问题快速排查
遇到 command not found 或 cannot find package 时，按顺序检查：
- 运行
which go和go env GOROOT，确认 Go 安装路径有效且未被覆盖 - 运行
echo $PATH，确认$GOPATH/bin在其中（尤其 macOS M1/M2 用户易漏掉zsh配置） - 在项目目录下执行
go list -m，有输出说明处于 module 模式；若报错not in a module，则可能误入 GOPATH 模式 - 临时禁用 module 测试兼容性：
GO111MODULE=off go build（仅调试用，勿提交）
