Go 1.22+ 安装后 go version 报 command not found，是 PATH 未生效所致：macOS/Linux 需手动将 Go 的 bin 目录（如 /usr/local/go/bin 或 $HOME/go/bin）添加到 shell 配置文件并 source；Windows 需在环境变量中配置且重启终端。
Go 1.22+ 已不再支持 GOROOT 手动设置（除非你刻意覆盖默认路径），绝大多数情况下，装完就可用，不用“搭建”——真正要花时间的，是搞清 GOBIN、GOPATH 和模块代理这三件事。
安装后直接运行 go version 报 command not found 怎么办
这是 PATH 没生效的典型表现。macOS/Linux 下，安装包（如 .pkg 或 tar.gz）通常不会自动把 bin 目录加进 shell 的 PATH；Windows 用户则容易忽略“重启终端”或“重新登录”。
- macOS：检查
~/go/bin是否在$PATH中，运行echo $PATH看一眼；若缺失，往~/.zshrc（或~/.bash_profile）里加一行：export PATH="$HOME/go/bin:$PATH" - Windows：用 PowerShell 运行
$env:Path查看，确认C:\Program Files\Go\bin（或你自定义的安装路径下的bin）在里面；没看到就右键“此电脑 → 属性 → 高级系统设置 → 环境变量”，编辑用户变量里的Path - 别用
sudo go install试图绕过权限问题——这会把二进制写到/usr/local/bin，但后续go mod操作仍依赖用户级GOPATH，反而引发权限错乱
go mod init 后 go run 提示 cannot find module providing package
这不是环境问题，是模块初始化不完整导致的依赖解析失败。常见于从旧项目复制代码、或手动新建 main.go 后忘了初始化模块。
- 确保当前目录下有
go.mod文件；没有就立刻执行go mod init example.com/myapp（模块名不必真实可访问，但不能是main或空字符串） - 如果已有
go.mod但依赖缺失，运行go mod tidy自动补全require和exclude；它会读import语句并拉取对应版本 - 注意：
go run main.go在模块外也能跑，但一旦用了第三方包（比如github.com/spf13/cobra），没go.mod就会报这个错——Go 不再默认 fallback 到GOPATH/src
国内环境下 go get 卡住或 timeout
Go 默认走 proxy.golang.org，国内直连基本不可用。必须显式配置模块代理，且推荐用官方认可的国内镜像。
立即学习“go语言免费学习笔记（深入）”；
- 执行
go env -w GOPROXY=https://goproxy.cn,direct（direct表示对私有域名跳过代理，比如公司内网git.corp.com） - 验证是否生效：运行
go env GOPROXY，输出应为https://goproxy.cn,direct - 别用已失效的代理如
https://golang.google.cn（2023 年底起已停服）；也别设成https://proxy.golang.org—— 它本身在国内就不可达 - 如果公司有私有模块仓库（如 Nexus + Go Proxy），需额外加
GONOPROXY，例如：go env -w GONOPROXY=git.corp.com,github.corp.com
真正麻烦的从来不是装 Go，而是当你在 CI 脚本里硬编码了 GOPATH、在 Makefile 里用 $(shell go env GOPATH) 拼路径、或者团队里有人还在用 go get github.com/xxx/yyy 直接装命令行工具——这些习惯在 Go 1.16+ 模块模式下极易出错，而且错误信息往往不指向根源。
