go version能运行不代表环境就绪，常见问题在于go111module、goproxy和goroot/gobin路径冲突，以及shell未加载go路径、ide缓存旧path、模块未初始化、代理未配置或gopath误设。
go version 命令能跑通，不等于环境真正就绪——多数人卡在 GO111MODULE、GOPROXY 和 GOROOT/GOBIN 路径冲突上，而非安装本身。
为什么 go version 成功后还编译失败？
常见现象是：终端里 go version 有输出，但执行 go run main.go 报错 command not found: go（macOS/Linux）或 'go' is not recognized（Windows），本质是 shell 没加载到刚装的 go 二进制路径。
- Windows 用户容易忽略「重启命令行」或「重启 PowerShell/CMD」——安装 .msi 后 PATH 是写入注册表的，旧终端进程不会自动重读
- macOS/Linux 用户常把
export PATH=$PATH:/usr/local/go/bin写在~/.zshrc却用bash打开终端，或写了但没执行source ~/.zshrc - 某些 IDE（如 VS Code）启动时会缓存旧的 PATH，需完全退出再重开，不能只关窗口
GO111MODULE=on 不是可选项，而是默认行为
Go 1.16+ 已强制启用模块（module）模式，GO111MODULE=auto 实际已失效。新手常因没初始化 module 就直接 go run，导致依赖无法解析或 import 报错。
- 新建项目务必先执行
go mod init example.com/hello，包名不必真实存在，但不能是空字符串或纯数字 - 若项目在
$GOPATH/src下，Go 仍可能降级为 GOPATH 模式，引发奇怪的cannot find package -
go list -m可确认当前是否处于 module 模式；输出含main行即正常
代理配置不是“锦上添花”，而是国内开发的刚需
不配 GOPROXY，go get 或 go mod download 极易卡在 proxy.golang.org，超时后 fallback 到源码仓库直连，大概率失败。
- 推荐一步到位：
go env -w GOPROXY=https://goproxy.cn,direct（国内可用）或https://proxy.golang.com.cn,direct（官方中国镜像） - 避免写成
https://goproxy.cn少了,direct—— 这会导致私有模块（如公司内网 git）无法拉取 - 验证是否生效：
go env GOPROXY输出应与设置一致；首次go mod download会明显变快
别碰 GOPATH，除非你明确要维护老项目
Go Modules 已取代 GOPATH 作为依赖管理核心，但很多教程仍教人配置 GOPATH，反而制造混乱。
- 现代项目无需设置
GOPATH；go命令会自动在当前目录向上查找go.mod - 若误设
GOPATH且值为非标准路径（如/my/gopath），可能导致go install编译的二进制被写到错误位置 - 检查是否冗余配置：
go env GOPATH输出应为默认值（如 macOS 是$HOME/go），若非必要，不要用go env -w GOPATH=...覆盖
go run 静默失败，或让 import 看似正常实则链接不到包。动手前先跑 go env 看一眼全量配置，比反复重装更省时间。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
