go command not found 的根本原因是 PATH 未包含 Go 二进制路径，需先运行 which go 或 where go 确认可执行文件是否存在，再检查 /usr/local/go/bin（Linux/macOS）或 C:\Go\bin（Windows）是否在 PATH 中，最后 source 配置文件或重启终端。
Go 环境没装好，go version 报 command not found，90% 是 PATH 没生效，不是没下载、也不是没解压——先查路径，再看变量，最后动配置。
go command not found 怎么快速定位原因
别急着重装，先用最简命令判断问题在哪：
- 运行
which go（Linux/macOS）或where go（Windows PowerShell），无输出说明系统根本找不到这个可执行文件 - 检查安装路径是否存在：比如
/usr/local/go/bin/go或C:\Go\bin\go.exe，不存在就说明解压/安装失败或路径错了 - 确认
PATH是否包含该路径：echo $PATH（Linux/macOS）或echo %PATH%（Windows CMD），看有没有/usr/local/go/bin或%GOROOT%\bin - 终端是否重启过？
.bashrc或.zshrc改了必须source ~/.zshrc；Windows 安装 .msi 后所有 CMD/PowerShell 窗口都得关掉重开
GOROOT 和 GOPATH 还需要手动设吗
GOROOT 必须设（除非你装在默认路径且系统自动配好了），GOPATH 在 Go 1.16+ 已非强制，但建议仍设——尤其当你用 go install 装工具（如 gopls、dlv）时，它们默认往 $GOPATH/bin 放二进制文件。
-
GOROOT指向 Go 安装根目录，例如/usr/local/go或C:\Go；设错会导致go env GOROOT输出异常，go build可能报找不到标准库 -
GOPATH默认是$HOME/go，但如果你改过，就得显式声明；不设的话，go get（已弃用）或旧脚本可能出错，且go mod vendor会拒绝工作 - 注意：不要把项目目录放在
$GOPATH/src下——这是 Go 1.11 前的老习惯，现在用模块模式，放这里反而会让go mod init推导出错误的 module 名
国内拉包总超时，GOPROXY 怎么配才真正生效
只跑 go env -w GOPROXY=https://goproxy.cn,direct 不够，必须确认三件事同时成立：
立即学习“go语言免费学习笔记（深入）”；
- 模块模式已开启：
go env GO111MODULE输出必须是on；如果还是auto或off，先执行go env -w GO111MODULE=on - 代理地址拼写正确：
https://goproxy.cn（不是http，不是goproxy.io），末尾,direct不能漏，否则私有仓库无法回源 - 校验和数据库同步：
go env -w GOSUMDB=sum.golang.org；设成off虽然能跳过验证，但会埋下依赖被篡改的风险，不推荐 - 验证是否生效：运行
go env | grep GOPROXY，输出应为完整配置项；再试go list -m golang.org/x/tools，5 秒内返回结果即成功
多个 Go 版本共存时容易踩哪些坑
不用删旧版也能切版本，但路径和环境变量容易打架：
- 不同版本的
GOROOT必须指向各自解压目录（如/usr/local/go-1.21和/usr/local/go-1.23），不能共用一个/usr/local/go - 切换时只改
GOROOT和PATH中的 bin 路径，别动GOPATH——它跟 Go 版本无关 - VS Code 的
gopls会读当前 workspace 的go命令路径，如果项目里用了go.work，确保它指定的版本与终端一致，否则编辑器提示和实际构建行为可能不一致 - CI/CD 脚本里硬编码了
go1.21，但本地 PATH 优先用了go1.23，测试通过但线上构建失败——这类问题只能靠go version显式校验
最麻烦的不是装不上，而是装上了但 go mod download 卡住、gopls 启不起来、或者换台机器就编译不过——这些几乎都卡在环境变量链路的某个断点上，逐层验证比重装更快。
