最直接的验证方式是运行go version看是否输出版本号；若失败则检查PATH配置、GOROOT/GOPATH/GOBIN环境变量、go run main.go是否可执行、go mod init是否能正常初始化模块。
直接运行 go version 看是否报错
这是最轻量、最无依赖的验证方式。只要 go 命令能被 shell 找到，就说明 GOROOT 和 PATH 至少有一部分生效了。
常见错误现象：command not found: go（Linux/macOS）或 'go' is not recognized as an internal or external command（Windows）——本质是 $GOROOT/bin 或 %GOROOT%\bin 没进 PATH，或者终端没重载配置。
- Windows 用户注意：修改环境变量后必须重启命令提示符/PowerShell，CMD 不继承新会话的变量
- macOS/Linux 用户若用 zsh，改了
~/.bash_profile却没生效，大概率是因为没同步到~/.zshrc；建议统一改~/.zshrc并执行source ~/.zshrc - 不要在安装目录双击
go.exe测试——它不是 GUI 程序，只会闪退；必须走终端
用 go env 确认关键变量是否被 Go 实际读取
go env 输出的是 Go 工具链最终解析出的环境，不是你 shell 里 echo $GOROOT 的值。两者不一致很常见，也恰恰说明问题在哪。
重点关注三项：
立即学习“go语言免费学习笔记（深入）”；
-
GOROOT：必须指向真实安装路径（如/usr/local/go或C:\Go），不能是空或错误路径 -
GO111MODULE：现代项目应为on；若显示auto或off，go mod init可能静默失败 -
GOPATH：Go 1.16+ 默认不强制要求，但若为空且你又在$GOPATH/src下操作，模块行为可能异常
执行 go env GOROOT GO111MODULE 比扫完整列表更快，适合脚本中快速断言。
跑一个 main.go 文件验证编译器和标准库联动
光有 go version 成功，不代表 fmt 包能加载、也不代表 go run 能工作。必须实际触发一次编译流程。
新建任意空目录，写入：
package main
import "fmt"
func main() {
fmt.Println("OK")
}
然后执行 go run main.go。
- 报错
cannot find package "fmt"：大概率GOROOT指向错误目录，或该路径下缺失src/fmt目录 - 报错
build failed: cannot load fmt：可能是文件编码含 BOM、换行符是 CRLF（尤其 Windows 上用某些编辑器保存时）、或当前目录已有go.mod但内容损坏 - 输出
OK即通过——不需要生成二进制，go run已完成全链路验证
go mod init 后 go list -m 验证模块系统可用
从 Go 1.11 开始，模块是默认构建单元。即使不依赖第三方包，也得确认模块解析器能正常初始化。
在刚才跑通 go run 的目录下执行：
-
go mod init example.com/test→ 应生成go.mod文件 -
go list -m→ 应精确输出example.com/test
如果 go list -m 报错或输出空，说明模块机制卡住。常见原因：
- 当前路径在
$GOPATH/src下且GO111MODULE=off，go mod init会降级为 GOPATH 模式，不生成go.mod - 父目录已有
go.mod，导致当前目录被纳入上层模块，go list -m显示的是父模块名 - 磁盘权限不足，无法写入
go.mod
模块验证不是可选项——现在几乎所有 CI、依赖管理、IDE 支持都基于模块，漏掉这步，后续 go get 或 go build 很可能在奇怪的地方失败。
