Go环境搭建是硬门槛，关键在GOROOT、GOPATH、GO111MODULE和GOPROXY四者协同：GOROOT指向Go安装路径，GOPATH为工作区（现代Go非强制但建议设置），GO111MODULE=on强制启用模块模式，GOPROXY需设为https://goproxy.cn,direct以保障依赖下载成功。
Go语言环境搭建不是“形式主义步骤”，而是直接影响后续所有操作是否能跑通的硬门槛。很多新手卡在go version报错、go mod init失败、甚至main.go根本运行不了，问题根源90%出在环境变量或模块配置上。
GOROOT 和 GOPATH 容易混淆，但必须分清
GOROOT 是 Go 工具链自身的位置（比如 /usr/local/go），由安装程序自动设好，一般不用改；GOPATH 是你写代码、放依赖的地方，默认是 $HOME/go，但现代 Go（1.16+）已默认启用 Go Modules，GOPATH 只影响 go get 旧式包安装和 go install 命令生成的二进制存放路径。
- 如果你用
brew install go（Mac）或.msi（Windows），GOROOT 通常已正确设置，go env GOROOT能查到值就说明没问题 - 手动解压 tar.gz 安装时，必须显式设置
GOROOT，否则go build可能找不到标准库 -
GOPATH不再强制要求，但建议仍设一个（如$HOME/go-workspace），避免某些工具（如旧版gopls）行为异常
GO111MODULE=on 是现代 Go 项目的事实标准
Go 1.11 引入 Modules 后，项目不再依赖 GOPATH/src 目录结构。GO111MODULE=on 强制启用模块模式，否则在非 GOPATH 下执行 go mod init 会静默失败，或 go run main.go 报 cannot find module providing package。
- 检查当前状态：运行
go env GO111MODULE，输出应为on - 如果输出空或
auto，在 shell 配置中加上export GO111MODULE=on并source生效 -
auto模式下，只有当前目录有go.mod或在GOPATH外才会启用模块——这个逻辑容易误判，直接设on更可靠
GOProxy 配置不当会导致 go mod download 卡死或失败
国内访问官方 proxy.golang.org 经常超时或 404，不配代理的话，go get 或 go mod tidy 会卡在 “verifying …” 或直接报 Get "https://proxy.golang.org/…": dial tcp …: i/o timeout。
立即学习“go语言免费学习笔记（深入）”；
- 推荐配置：
export GOPROXY=https://goproxy.cn,direct（goproxy.cn由七牛云维护，稳定可用） - 注意末尾的
,direct：它表示当代理无法命中时，回退到直接从模块源拉取（比如私有 Git 仓库） - 避免只写
https://goproxy.cn不加,direct，否则私有模块将完全无法解析
真正麻烦的从来不是“装不上”，而是装上了却不知道哪一步悄悄失效了——比如 GOROOT 被多个安装方式覆盖、GO111MODULE 在某个子 shell 里没继承、或者 GOPROXY 配错导致依赖拉了一半就中断。这些细节不会报明显错误，但会让 go run 突然失败，且错误信息毫无指向性。
