Go环境稳健与否取决于GOROOT、GOPATH、GO111MODULE、GOPROXY四变量是否明确可控，且需规避MSI安装后未重启终端等失效点；go version成功不等于环境可用，须通过go mod init、go run、go mod tidy、go install四步闭环验证，并注意GOSUMDB国内访问问题。
直接上结论：Go 环境是否“稳健”，不取决于是否装上了 go 命令，而在于 GOROOT、GOPATH、GO111MODULE、GOPROXY 四个变量是否明确且可控，以及是否跳过了 Windows MSI 安装后不重启终端这类低级但高频的失效点。
go version 能跑 ≠ 环境就稳健
很多开发者执行 go version 成功就以为万事大吉，结果一跑 go mod download 就卡住，或 go run 报 cannot find module providing package。根本原因不是 Go 没装好，而是模块机制和代理没对齐。
-
GO111MODULE必须显式设为on（尤其在 GOPATH 外建项目时），否则go mod init会静默失败或退化到老式GOPATH模式 -
GOPROXY不配国内源（如https://goproxy.cn,direct），go get或go mod tidy在国内基本不可用，超时是常态，不是网络问题 - Windows 用户用
.msi安装后，必须关闭并重开所有 CMD/PowerShell——环境变量不会自动广播给已存在的进程 - Linux/macOS 下改了
~/.zshrc却忘了source ~/.zshrc，或者误改了~/.bash_profile但 shell 实际加载的是~/.zshrc，也会导致which go找不到命令
GOROOT 和 GOPATH 的实际分工要分清
GOROOT 是 Go 运行时本身的位置，GOPATH 是你写代码、放依赖、产出二进制的地方——二者不能混为一谈，也不能随意指向同一路径。
-
GOROOT应固定为安装目录（如/usr/local/go或C:\Program Files\Go），不要手动修改它；若用apt install golang，系统通常已设好，无需再 export -
GOPATH推荐保持默认$HOME/go，不建议改成项目目录或/tmp；它的src子目录只在传统 GOPATH 模式下有意义，Go Modules 启用后可忽略，但pkg和bin仍被go install使用 - Go 1.16+ 已默认启用 Modules，
GOPATH不再决定项目位置，你完全可以在~/project/api目录下go mod init example.com/api，无需把代码塞进$GOPATH/src - 如果同时维护多个 Go 版本（如测试兼容性），不要靠改
GOROOT切换，应使用gvm或直接调用不同路径下的go二进制（如/usr/local/go1.21/bin/go）
验证环境是否真可用，别只看 go version
真正有效的验证，是模拟一个最小闭环：从初始化、拉依赖、编译到运行。
立即学习“go语言免费学习笔记（深入）”；
- 新建空目录，执行：
go mod init testenv—— 成功生成go.mod才算 Modules 就绪 - 写一个极简
main.go，内容仅含package main; func main() { println("ok") }，然后运行：go run main.go—— 成功输出才说明工具链无断裂 - 加一行
import "golang.org/x/net/http2"，再执行：go mod tidy—— 不卡住、不报错、生成go.sum，才算GOPROXY和校验机制生效 - 执行：
go env -w GOBIN=$HOME/bin，再go install golang.org/x/tools/cmd/goimports@latest，最后检查$HOME/bin/goimports是否存在 —— 验证GOBIN和用户级二进制安装路径是否通
最容易被忽略的其实是 GOSUMDB。它默认指向 sum.golang.org，国内直连不稳定，会导致 go get 卡在 checksum 校验阶段，现象是“看起来在下载，但进度条不动”。这个值不像 GOPROXY 那样常被提及，但缺它，环境就是半残的。
