Go环境搭建是多数错误的根因；需正确配置PATH指向go二进制目录，GOROOT通常无需设置，GOPATH仅影响无模块时的依赖路径和install输出，GO111MODULE应统一设为on以避免模式混淆。
Go 语言环境搭建不是“前置步骤”，而是你第一次 go run 失败时，所有后续问题的根因。90% 的 “undefined: xxx”、“command not found: go”、“GO111MODULE=off 导致依赖不加载” 都卡在这一步。
PATH 没配对，go 命令就永远找不到
下载二进制包或用包管理器安装后，go 可执行文件实际在 /usr/local/go/bin（macOS/Linux）或 C:\Go\bin（Windows）。但系统默认不查这个路径。
- Linux/macOS：必须把
export PATH=$PATH:/usr/local/go/bin写进~/.zshrc或~/.bash_profile，然后source它；只改当前终端的PATH是临时的，新开终端就失效 - Windows：得手动加到「系统环境变量」的
Path里，不是用户变量——很多教程漏了这点，导致 VS Code 终端能用、命令行也能用，但 IDE 内置终端或 Git Bash 就报错 - 验证方式不是
which go，而是go version—— 因为有些旧版 shell 缓存了命令位置，which显示有，但实际调用的是别的东西
GOROOT 和 GOPATH 到底还用不用设？
Go 1.16+ 默认启用模块（modules），GOROOT 一般不用设——只要 go 命令能运行，它自己就知道装在哪。但 GOROOT 设错会直接导致 go build 找不到标准库。
- 除非你同时装了多个 Go 版本并用
gvm或asdf切换，否则别碰GOROOT -
GOPATH在模块模式下已退居二线：它只影响go get无go.mod时的下载位置，以及go install二进制的存放（默认是$GOPATH/bin）。你可以不设，Go 会用$HOME/go作为默认值 - 但如果你设了
GOPATH，就必须确保$GOPATH/bin也在PATH里，否则go install出的命令无法全局调用
GO111MODULE 开关不一致，依赖行为完全不可控
这个环境变量决定 Go 是走老式 GOPATH 模式，还是现代模块模式。它的值不是布尔，而是字符串：on / off / auto，且优先级高于 go.mod 是否存在。
立即学习“go语言免费学习笔记（深入）”；
-
GO111MODULE=off：彻底禁用模块，哪怕目录里有go.mod也当没看见，所有依赖从GOPATH拉——这是初学者 clone 项目后go run .报 “cannot find module providing package” 的最常见原因 -
GO111MODULE=auto（Go 1.16+ 默认）：有go.mod就用模块，没就 fallback 到GOPATH；但若项目在$GOPATH/src下，即使有go.mod，也会被强制降级为 GOPATH 模式 - 建议统一设为
GO111MODULE=on，并在项目根目录运行go mod init example.com/myapp显式开启模块——避免隐式行为干扰
真正麻烦的从来不是“怎么装”，而是装完之后，go env 输出里哪几行不对劲、哪个路径少了一个 /bin、哪个环境变量在某个 shell 里没生效——这些细节不会报错，只会让后续每一步都慢半拍、错一点、查半天。
