Go环境搭建核心是适配1.16+模块模式：GOROOT指向安装目录，GOPATH仅用于$GOPATH/bin存放工具，项目可放任意路径并需go mod init生成go.mod；PATH只需含$GOROOT/bin和$GOPATH/bin；验证需执行go env GOPROXY、go mod init及go run -u golang.org/x/tools/gopls@latest。
go 环境搭建不是“装完就完事”的一次性操作，它直接决定后续 go run、go build、go mod 是否能正常工作，以及项目是否能跨机器复现。核心问题从来不是“能不能装上”，而是“路径和模块行为是否符合当前 Go 版本的默认逻辑”。
确认你用的是 Go 1.16+（必须）
Go 1.16（2021年2月发布）起，默认启用 GO111MODULE=on，不再依赖 GOPATH/src 目录结构。如果你还在照着 2019 年前的教程配 GOPATH 并把代码硬塞进 $GOPATH/src/github.com/xxx，go mod init 会报错或行为异常。
- 运行
go version，确保输出类似go version go1.21.10 linux/amd64（2026 年主流是 1.21.x 或 1.22.x） - 如果版本低于 1.16，请直接卸载重装——旧版环境配置方式与现代项目完全不兼容
- 不必手动设
GO111MODULE，新版默认开启；设成off反而会让go get失效
GOROOT 和 GOPATH 现在分别管什么？
很多人被这两个变量绕晕，其实它们分工已非常清晰：
-
GOROOT：只指向 Go 安装目录（如/usr/local/go或C:\Go），由安装程序自动设置，**用户一般不用改** -
GOPATH：仅用于存放go install生成的可执行文件（即$GOPATH/bin），以及老式go get下载的包（现已不推荐）；它和你的项目源码位置无关 - 你的项目可以放在任意路径（
~/projects/myapp、D:\code\api），只要该目录下有go.mod，就是合法模块根目录
PATH 配置只加两处，别多加
PATH 错误是 command not found: go 或 go: command not found 的最常见原因。只需确保 PATH 包含：
立即学习“go语言免费学习笔记（深入）”；
-
$GOROOT/bin（让系统找到go命令本身） -
$GOPATH/bin（让系统找到你go install的二进制，比如gopls、dlv） - 不要把
$GOPATH或$GOPATH/src加进 PATH —— 它们不是可执行路径 - Linux/macOS 编辑
~/.zshrc或~/.bashrc；Windows 在系统环境变量里配，别用用户变量覆盖系统变量
验证是否真可用，别只信 go version
go version 成功只说明命令存在，不代表模块、网络、工具链就通了。必须跑这三步：
-
go env GOPROXY：应输出类似https://proxy.golang.org,direct；若为空，go mod download会超时 -
go mod init example.com/test（在空目录下执行）：成功生成go.mod文件才算模块系统就绪 -
go run -u golang.org/x/tools/gopls@latest：拉取并安装语言服务器，这是 VS Code / GoLand 能智能提示的前提；失败往往暴露代理或证书问题
真正麻烦的永远不是“装不上”，而是 go mod 卡在 proxy、gopls 启动失败、或者 go test 找不到本地包——这些都源于环境变量和模块模式的隐性冲突。
