Go环境配置关键在于验证GOROOT、GOPROXY和go version三者一致性：GOROOT需指向真实安装路径，GOPROXY须设为国内代理如goproxy.cn，go version输出应含平台标识，三者缺一不可。
Go 环境现在基本不用手动配 GOPATH 了，装好 Go 二进制、设对 GOROOT 和 PATH、顺手换国内代理，5 分钟内就能跑 go run —— 剩下的都是可选动作，别被老教程带偏。
go version 和 go env 检查是否真装好了
很多人输完 go version 看到输出就以为万事大吉，其实可能只是 PATH 里混进了旧版本或别的 Go 安装路径。真正要确认的不是“有没有”，而是“用的是不是你刚装的那个”。
- 运行
go version，看输出里带不带linux/amd64、darwin/arm64这类平台标识，没有说明没装对或没生效 - 紧接着跑
go env GOROOT，输出必须是你解压/安装 Go 的真实路径（比如/usr/local/go或C:\Program Files\Go），而不是空或$HOME/sdk/go这类模糊值 - 再执行
go env GOPROXY，国内用户必须看到类似https://goproxy.cn,direct或https://mirrors.cloud.tencent.com/go/,direct，否则go mod tidy会卡住或报Get "https://proxy.golang.org/..."错误
Linux/macOS 手动安装后 PATH 和 GOROOT 必须显式声明
Homebrew 或 pkg 安装器会自动把 go 命令塞进 /usr/local/bin，但 GOROOT 不一定被设 —— 而很多 IDE（如 Goland）、CI 脚本、甚至 go test -race 都依赖它。不设等于埋雷。
- 编辑
~/.zshrc（macOS）或~/.bashrc（Linux），加这两行（路径按你实际安装位置改）：export GOROOT=/usr/local/goexport PATH=$PATH:$GOROOT/bin - 别漏掉
source ~/.zshrc（或对应文件），否则新开终端还是旧环境 - 验证：关掉终端重开，再跑
which go和go env GOROOT，两个输出路径要一致
go mod init 后 go.sum 文件为空？那是没拉依赖
新建项目时只跑 go mod init myapp，go.sum 确实是空的 —— 这正常，它只在首次 go mod download 或 go build 遇到远程依赖时才生成校验和。但很多人误以为“没生效”，接着乱删 go.mod 重来，反而触发缓存污染。
立即学习“go语言免费学习笔记（深入）”；
- 只要
go.mod里有module myapp和go 1.21（或更高）就行，不用管go.sum是否为空 - 真正要检查的是：写一行
import "github.com/gorilla/mux"，然后执行go mod tidy—— 这时go.sum才该有内容，且go.mod里会出现require github.com/gorilla/mux v1.8.0 - 如果
go mod tidy卡住，先确认go env GOPROXY是国内源；若仍失败，临时加-v参数看卡在哪条 URL 上
go run 和 go build 的输出位置容易混淆
go run main.go 是编译+执行+删临时文件，看不到可执行文件；go build main.go 默认生成同名可执行文件（main 或 main.exe）在当前目录 —— 但很多人试完 go run 就以为“已经编译过了”，结果 ./main 报错“no such file or directory”。
-
go build不加参数时，输出名 = 主文件名（不含.go），比如go build server.go→ 输出server - 想指定输出路径和名字，用
-o：go build -o ./bin/myapp main.go -
go install会把可执行文件放进$GOBIN（默认是$GOPATH/bin），但模块模式下需确保项目根目录有go.mod且go install后面跟的是包路径（如./cmd/myapp），不是文件名
最常被跳过的其实是 go env GOPROXY 和 go env GOROOT 的双重验证 —— 它们不像 go version 那么显眼，但出问题时症状分散：依赖拉不下来、IDE 找不到 SDK、go test 报奇怪的构建错误。动手前花 30 秒查清楚，比后面花半小时排查强。
