Mac用Homebrew、Windows用.msi、Linux解压到/usr/local/go可避环境变量坑；go version报错主因PATH未生效；GOROOT无需手动设，GOPATH建议设为$HOME/go并加入PATH；GO111MODULE=on应显式开启。
Mac 上装 Go，Homebrew 是最省心的选择；Windows 用官方 .msi 安装包就行；Linux 推荐手动解压到 /usr/local/go —— 这三种方式都能避开绝大多数环境变量坑。
go version 命令报错：command not found
这是刚装完 Go 最常遇到的问题，本质是 PATH 没生效。不是没装好，而是 shell 找不到 go 可执行文件。
- Mac（zsh 默认）：检查
~/.zshrc是否包含export PATH=$PATH:/usr/local/go/bin（官方 pkg 安装路径）或export PATH=$PATH:$(brew --prefix)/go/bin（Homebrew 路径） - Linux：确认
/usr/local/go/bin已加入PATH，且执行过source ~/.bashrc或source ~/.zshrc - Windows：安装 .msi 后需重启终端，或者手动检查系统环境变量里
Path是否含C:\Program Files\Go\bin - 验证方式：直接运行
echo $PATH（Mac/Linux）或echo %PATH%（Windows），看输出里有没有 go 的 bin 目录
GOROOT 和 GOPATH 还需要手动设吗？
2026 年的 Go（1.22+）已大幅简化环境变量逻辑：GOROOT 几乎不用设 —— 安装程序或 Homebrew 都会自动定位；GOPATH 在启用 Go Modules 后也不再强制要求项目放固定目录，但仍有两个实际用途：
-
GOPATH决定go install生成的二进制文件存放位置（默认是$GOPATH/bin），建议保留并确保它在PATH中 - 第三方工具（如某些旧版 linter）可能仍读取
GOPATH，设成$HOME/go是最稳妥的兼容写法 -
GO111MODULE=on应该显式开启（加到 shell 配置中），避免意外退回到 GOPATH 模式
go mod init 报错：no module found for path
这个错误通常不是模块初始化失败，而是当前目录不在 GOPATH/src 下、又没启用 Modules —— 但在 Go 1.16+ 默认开启 Modules 的前提下，更可能是以下原因：
立即学习“go语言免费学习笔记（深入）”；
- 当前目录已有
go.mod文件但内容损坏，删掉重试即可 - 父目录存在
go.mod（比如你在某大项目的子目录里执行），Go 会沿路向上查找，导致初始化路径冲突 - 项目名用了非法字符（如空格、中文、下划线开头），
go mod init要求模块路径符合 Go 包命名规范，推荐用 GitHub 风格：github.com/yourname/projectname - 没开
GO111MODULE且当前不在$GOPATH/src下，会直接报这个错 —— 此时运行go env -w GO111MODULE=on即可
VS Code 里 gopls 提示 “failed to load workspace”
这不是 Go 安装问题，而是编辑器插件没识别到模块根目录。gopls 依赖 go.mod 文件定位项目边界。
- 确保项目根目录有有效的
go.mod（哪怕只是空模块，go mod init example.com/foo就行） - 不要把 VS Code 工作区打开在
$GOPATH根目录或src目录下 —— 它会试图加载整个 GOPATH，超慢还报错 - 如果用了多模块仓库（monorepo），每个子模块需独立有
go.mod，且 VS Code 应打开具体子目录，而非顶层 - 重启 VS Code 或执行命令面板里的
Developer: Reload Window，gopls 有时缓存了旧路径
真正容易被忽略的是：Go Modules 不是“开关”，而是一套路径解析逻辑 —— go run、go build、gopls 全部依赖它，只要模块路径写错或 go.mod 缺失，所有环节都会连锁异常，而不是只在某个命令里报错。
