go version报command not found时，通常不是未安装Go，而是PATH未生效或指向错误路径；需检查where go/which go输出、GOROOT一致性、重启终端，并清理IDE缓存与环境变量残留。
go version 报 command not found 时先别重装
这通常不是环境没装，而是 PATH 没生效或指向了错误路径。Windows 上 MSI 安装器默认会加 C:\Program Files\Go\bin 到系统 Path，但如果你手动解压过 zip 包、用过 scoop/choco、或改过安装路径，就可能残留多个 go 二进制，导致终端调用混乱。
执行以下检查：
- 运行
where go（Windows）或which go（macOS/Linux），看输出是否唯一且指向你预期的安装目录 - 检查
go env GOROOT输出是否和where go的上级目录一致；不一致说明GOROOT被错误设置了 - 打开新终端（不是“刷新”旧窗口），再试
go version—— IDE 或旧终端常缓存 PATH，重启才生效
删掉所有手动设置的 GOROOT 和 GOPATH 再验证
Go 1.16+ 默认启用模块模式后，GOROOT 几乎不需要手动设（除非你同时维护多个 Go 版本），GOPATH 也只用于存放 go install 编译出的可执行文件（即 $GOPATH/bin），不再是源码根目录。
容易踩的坑：
立即学习“go语言免费学习笔记（深入）”；
- 在环境变量里硬编码了
GOROOT=C:\go，但实际安装在C:\Program Files\Go，会导致go build找不到fmt等标准库，报错类似cannot find package "fmt" - 设置了
GOPATH却没把%GOPATH%\bin加进 Path，导致go install .成功但命令无法全局调用 - 误以为
GOPATH必须存在才能写代码 —— 实际上只要项目里有go.mod，go run就完全不依赖它
建议：直接删除系统/用户变量里的 GOROOT 和 GOPATH，让 Go 自动推导；再运行 go env 确认输出是否干净合理。
清理残留的 go mod 缓存和 proxy 配置
如果 go get 或 go mod download 经常失败、超时或拉到错误版本，问题往往不在环境变量，而在模块缓存或代理配置残留。
执行这些命令清空干扰项：
-
go clean -modcache：删掉本地下载的所有模块源码（$GOMODCACHE，默认在$GOPATH/pkg/mod） -
go env -u GOPROXY：取消手动设置的代理，回退到 Go 默认行为（https://proxy.golang.org,direct） -
go env -w GOSUMDB=off：临时关闭校验（仅调试用，上线前应恢复） - 删掉项目根目录下的
go.sum和go.mod，重新go mod init example.com/myapp初始化（注意模块名不能含大写或下划线）
IDE 缓存比系统环境变量更难察觉
VS Code 的 Go 插件、GoLand、甚至 Sublime Text 的 GoSublime，都会在首次启动时读取并缓存一次 GOROOT 和 GOPATH。改完系统变量后不重启编辑器，它仍按旧值找 SDK、提示“package not found”或无法跳转定义。
验证方式很简单：
- 在 VS Code 中打开命令面板（
Ctrl+Shift+P），输入Go: Locate Configured Go Tools，看它列出的gopls、go路径是否正确 - 在 GoLand 里进入
File → Settings → Go → GOROOT，确认下拉菜单选中的是当前有效路径，不是灰掉的旧条目 - 最彻底的办法：关掉所有编辑器，删掉
~/.vscode/extensions/golang.go-*（macOS/Linux）或%USERPROFILE%\.vscode\extensions\golang.go-*（Windows）再重装插件
真正麻烦的从来不是“怎么装”，而是“哪个地方记住了旧配置却没告诉你”。PATH、GOROOT、GOPATH、IDE 缓存、go mod cache —— 这五处任何一处没清干净，都可能让 go run 看似正常，但 go test 或 go install 突然失败。
