PATH和GOPATH必须分开设置：PATH决定go等命令能否执行，需包含$GOROOT/bin；GOPATH仅影响go install输出位置及旧项目兼容，Go 1.16+模块项目中非必需，但显式设置$HOME/go并将其$GOPATH/bin加入PATH可避免CI或多用户环境问题。
PATH 和 GOPATH 必须分开设置，不能混为一谈
很多人在配置 Go 环境时，把 PATH 和 GOPATH 当成一回事，结果 go build 能跑，但 go get 报错、go mod download 找不到缓存、第三方包 import 失败——根源就是路径语义被混淆了。
PATH 只控制命令能否执行（比如你敲 go，系统去哪找这个二进制）；GOPATH 是旧版 Go 的工作区根目录，影响 src/pkg/bin 三件套存放位置；而 Go 1.16+ 默认启用 module 模式后，GOPATH 对依赖下载已无直接影响，但它仍决定 go install 生成的可执行文件放哪（默认落到 $GOPATH/bin）。
-
PATH必须包含 Go 安装路径下的bin目录，例如/usr/local/go/bin -
GOPATH推荐显式设为用户目录下的独立路径，如$HOME/go，避免和系统路径冲突 - 若不设
GOPATH，Go 会 fallback 到$HOME/go，但隐式行为容易在 CI 或多用户环境出问题
Linux/macOS 下 ~/.bashrc 和 ~/.zshrc 选哪个？看 shell 实际类型
用 echo $SHELL 看输出，别猜。Zsh 成为 macOS 默认 shell 已多年，Ubuntu 22.04+ 也默认用 bash，但很多开发者手动切了 zsh（尤其配了 oh-my-zsh）。写错配置文件等于白配。
常见错误现象：go version 在终端里能运行，新开一个终端就报 “command not found”——大概率是改了 .bashrc，但当前 shell 实际读的是 .zshrc。
立即学习“go语言免费学习笔记（深入）”；
- 确认 shell 类型：
ps -p $$或echo $SHELL - 只往实际生效的 shell 配置文件里追加：
echo "export PATH=\$PATH:/usr/local/go/bin" >> ~/.zshrc - 改完必须重载：
source ~/.zshrc（不是source ~/.bashrc） - 验证是否生效：
which go应返回/usr/local/go/bin/go
Windows 上 GOBIN 和 %PATH% 的双层陷阱
Windows 用户常忽略 GOBIN 环境变量，导致 go install 生成的命令找不到。它和 %PATH% 是两道关卡：前者决定二进制写入哪，后者决定系统能不能执行它。
典型症状：go install github.com/cpuguy83/go-md2man@latest 成功，但敲 md2man 提示“不是内部或外部命令”。
-
GOBIN默认为空，此时go install会把可执行文件放进%GOPATH%\bin - 必须确保该目录（如
C:\Users\Alice\go\bin）已加入%PATH% - PowerShell 中设置：
$env:GOBIN="C:\Users\Alice\go\bin"，然后$env:Path += ";C:\Users\Alice\go\bin" - cmd 中设置：
setx GOBIN "C:\Users\Alice\go\bin"+setx Path "%Path%;C:\Users\Alice\go\bin"（注意需重启 cmd）
go env 输出里 GOROOT 和 GOPATH 的值为什么不能一样？
如果 go env GOROOT 和 go env GOPATH 返回相同路径（比如都指向 /usr/local/go），说明安装方式有误——你可能把源码解压到了 GOPATH 下，或者用包管理器（如 apt）装了非官方二进制并手动改了环境变量。
后果很直接：go get 会尝试往 Go 安装目录里写第三方包，权限失败；go mod tidy 可能静默跳过某些依赖；更糟的是，升级 Go 版本时整个 GOPATH 被覆盖，项目全丢。
-
GOROOT是 Go 编译器和标准库所在位置，由安装过程确定，用户不该手动改 -
GOPATH必须是用户可写的独立目录，且不能是GOROOT的子目录 - 检查命令：
go env GOROOT应类似/usr/local/go，go env GOPATH应类似$HOME/go - 若两者重叠，删掉错误的
GOPATH设置，重新 export
export，实际是 Go 运行时查找逻辑的底层契约。一个字母写错、一个斜杠方向反了、一个 shell 配置文件选错，都可能导致后续所有模块下载、构建、安装行为不可预期。最稳妥的做法，永远是改完立刻用 go env 和 which go 交叉验证，而不是等跑 go run main.go 失败了再回头查。 
