最直接验证方式是终端执行go version，输出目标版本号且which go指向预期安装路径；go env GOROOT须为SDK根目录；go run内联代码成功输出“OK”才证明编译器、标准库与运行时连通。
Go 环境装没装对、能不能跑起来，最直接的验证方式就是终端里敲几条命令——不是看有没有报错，而是看输出是否符合预期、版本是否匹配项目要求、GOROOT 和 GOBIN 是否指向合理路径。
检查 go version 输出是否可信
很多人看到 go version 有输出就以为环境 OK，但实际可能是旧版本残留、多版本共存未切换、甚至 PATH 里混进了非官方二进制。关键要看三件事：
-
go version输出的版本号（比如go1.22.0）是否是你安装的目标版本 - 执行
which go确认路径是否落在你预期的安装目录下（如/usr/local/go/bin/go或~/sdk/go/bin/go） - 如果用
asdf或gvm管理多版本，额外运行asdf current golang或gvm list确认当前激活版本
常见陷阱：macOS 上通过 Homebrew 安装后，go version 显示正常，但 which go 指向 /opt/homebrew/bin/go —— 这是符号链接，得再 ls -l /opt/homebrew/bin/go 看真实路径是否指向 brew 安装的 SDK，否则可能和 GOROOT 冲突。
go env 里哪些字段必须人工核对
go env 打印的是 Go 构建链路的底层配置，其中 4 个字段出错会导致后续 go build、go test 行为异常，必须逐一手动比对：
立即学习“go语言免费学习笔记（深入）”；
-
GOROOT：应指向你安装的 Go SDK 根目录（如/usr/local/go），不能是用户家目录下的某个子路径；若被误设为~/go，go install会静默失败 -
GOBIN：建议显式设置（如~/go/bin），避免默认落到$GOROOT/bin导致权限问题或覆盖系统 Go -
GOPATH：Go 1.16+ 已默认启用 module 模式，GOPATH仅影响go install的二进制存放位置；若为空，go install会尝试写入$GOROOT/bin并报 permission denied -
GO111MODULE：推荐设为on，否则在非src目录下运行go test可能因找不到go.mod而报cannot find module providing package
用 go run 快速验证编译器与运行时连通性
光看命令存在、环境变量正确还不够，得让 Go 真正编译并执行一段代码。别写 hello world 文件，直接用内联方式测试：
go run <(echo 'package main; import "fmt"; func main() { fmt.Println("OK") }')
这条命令绕过文件系统，直接把源码传给 go run，能同时验证：go 命令可调用、编译器工作正常、链接器能找到标准库、运行时能启动 goroutine。如果卡住、报 exec: "gcc": executable file not found，说明缺失 C 工具链（macOS 需 xcode-select --install，Linux 需 build-essential 或 gcc-c++）。
模块初始化 + 依赖拉取是最后一道门槛
很多开发者本地能跑 go run，但一到 go test 就失败，原因是没真正走通 module 流程。进入一个空目录，执行：
go mod init example.com/test go get github.com/stretchr/testify/assert@v1.8.4
观察两点：
- 是否生成了
go.mod和go.sum -
go get是否成功下载并校验了assert包（注意不是go install，后者在 Go 1.21+ 默认不写入GOPATH/bin）
如果 go get 报 unknown revision v1.8.4 或超时，大概率是 GOPROXY 设置问题，临时加 export GOPROXY=https://proxy.golang.org,direct 再试。国内环境建议设为 https://goproxy.cn,direct。
真正容易被忽略的点在于：go env -w 写入的配置可能被 shell 启动脚本里的重复 export 覆盖，所以每次改完环境变量，都要新开一个终端再测，而不是在当前 shell 里 source ~/.zshrc 就以为生效了。
