真能跑通go run、go build、go mod tidy才算环境就位；which go与go env GOROOT必须路径一致，go mod init需在干净根目录执行，go list -m all是关键验证点。
Go 环境“一键搭建”只是表象，真能跑通 go run、go build、go mod tidy 三件事，才算环境就位。光 go version 成功，90% 的人其实还没真正用上 Go。
which go 和 go env GOROOT 不一致？PATH 或 GOROOT 肯定设错了
很多人执行 go version 有输出，就以为装好了。但 which go 返回空，或指向 /usr/bin/go（系统旧包），或 go env GOROOT 是空、是 /home/xxx/go，说明环境变量没生效或手动设错。
-
which go必须指向你解压的路径，比如/usr/local/go/bin/go或$HOME/local/go/bin/go -
go env GOROOT必须和上面路径的父目录完全一致（去掉/bin/go） - 如果
which go报错，检查source ~/.bashrc或source /etc/profile是否执行；echo $PATH看$GOROOT/bin是否在最前面 - 如果
go env GOROOT错了，运行go env -w GOROOT=""清掉手动设置，让 Go 自动推导（1.21+ 默认行为）
go mod init 失败报 “cannot find module providing package”？不是网络问题，是路径不对
这个错误和 GOPROXY 无关，纯粹是当前目录不满足模块初始化前提：它必须是干净的项目根，且不能嵌套在 ~/go/src/... 这类旧 GOPATH 结构里。
- 先
cd到你想放go.mod的目录，确保该目录下没有go.mod文件 - 不要在
~/go/src/github.com/user/project下执行 —— Go Modules 会忽略src这层，导致识别失败 - 运行
go mod init example.com/myapp（模块名不能是main，也不必是真实域名） - 已有混乱的
go.mod？直接rm go.mod go.sum，重来，别用go mod edit修
go run 和 go build 行为差异直接影响调试与交付
开发时用 go run 很快，但它不生成二进制、不保留调试符号、不支持交叉编译——这些恰恰是验证环境完整性的关键点。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
-
go run main.go只适用于单文件快速验证；多文件项目必须用go run .（注意结尾的点） -
go build默认产出同目录名的可执行文件，想指定名字用go build -o myapp - 需要调试（如用
dlv）？必须go build -gcflags="all=-N -l"再运行，go run不支持 - 在 Linux 容器（如 Codespaces）里编译，产物默认是 Linux 二进制；想给 macOS 用，得加
GOOS=darwin GOARCH=arm64 go build -o myapp
局域网服务器或多用户环境，千万别共享 GOROOT
用 sudo tar -C /usr/local 装 Go 看似省事，但在 NFS 挂载的家目录、多人共用的跳板机上，会引发缓存锁死、go build 静默失败、go tool compile 找不到命令等疑难问题。
- 每个用户必须独立解压到自己家目录，例如
$HOME/local/go - 显式导出
GOROOT、GOPATH、GOBIN、GOCACHE，全部指向用户私有路径 -
GOCACHE尤其不能共用，NFS 上并发写会卡住构建；推荐设为$HOME/.cache/go-build -
GOBIN=$HOME/bin，避免go install出的工具污染系统/usr/local/bin
最常被跳过的验证点：在目标环境中执行一次 go list -m all。它不下载代码，只校验模块图是否可解析——如果这步卡住或报错，说明 GOPROXY、GOSUMDB 或模块初始化本身就有隐性问题，比 go run 成功更早暴露环境缺陷。
