答案是：go version报“command not found”根本原因是shell找不到go二进制文件，需将安装目录下的bin路径（如/usr/local/go/bin）正确加入path；goroot通常自动推导，无需手动设置；go mod init卡住多因代理未配国内镜像或gocache缓存错误。
Go 环境能跑起来，不靠玄学，靠三个可验证的执行环节：二进制路径可访问、GOROOT 能被定位、模块初始化不卡在代理或缓存上。其他所有“配置失败”现象，基本是这三个环节中某一个断开了。
为什么 go version 报 “command not found”？
这不是 Go 没装好，而是 shell 找不到 go 这个可执行文件。
-
go命令实际位于安装目录下的bin/子目录里（如/usr/local/go/bin/go），必须把该路径加进PATH - Windows 用户常误把
GOROOT（如C:\Go）直接加进PATH，但正确路径是%GOROOT%\bin - macOS/Linux 用户改了
~/.zshrc却没运行source ~/.zshrc，新终端窗口也未重启，PATH 仍旧 - 某些 IDE（如 VS Code）启动时不会自动加载 shell 的环境变量，需从终端中用
code .启动才能继承 PATH
GOROOT 还需要手动设吗？
绝大多数情况——不需要。Go 自 1.0 起就能自动推导 GOROOT：只要 go 命令本身可执行，它就能向上回溯找到自己的安装根目录。
- 只有当你把
go二进制软链接到别处（比如/usr/local/bin/go→/opt/mygo/bin/go），且原始路径结构被破坏时，才可能需要显式设置GOROOT - 手动设错
GOROOT（比如指向空目录或权限不足的路径）会导致go build找不到标准库，报错类似cannot find package "fmt" -
go env GOROOT是唯一可信来源，不要依赖文档里写的“通常为 /usr/local/go”来硬编码
为什么 go mod init 卡住不动？
不是代码问题，是网络或缓存策略在拦截模块元数据请求。
- 默认代理
https://proxy.golang.org在国内直连大概率超时；必须配国内镜像，例如：go env -w GOPROXY=https://goproxy.cn,direct - 如果之前失败过，
go会把错误响应缓存进GOCACHE（默认在~/Library/Caches/go-build或$HOME/.cache/go-build），导致重试时直接返回旧错误；可临时清空：go clean -modcache -
GO111MODULE=on是现代 Go 的默认行为（1.16+），但若项目目录下有vendor/且GO111MODULE=auto，可能退回到 vendor 模式，而 vendor 为空就静默失败
真正容易被忽略的是：Go 不依赖 GOROOT 或 GOPATH 来编译单个文件（go run main.go 完全不看它们），但一旦涉及包导入、依赖解析、测试发现或工具链调用（如 go fmt），就会立刻检查模块根目录是否存在 go.mod，以及该文件声明的 module 名是否与当前路径匹配——这里出错，不会报“找不到 go.mod”，而表现为“unknown revision”或“no required module provides package”。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
