go命令找不到的主因是path未生效：windows需重启终端，macos/linux需手动添加/usr/local/go/bin到shell配置并source；goroot和gopath在go 1.16+模块模式下基本无需配置。
go 命令找不到？先确认 PATH 是否真生效
很多人装完 Go 就执行 go version 报 command not found，不是没装好，是 PATH 没生效。Windows 的 MSI 安装器默认加了 C:\Go\bin 到系统 PATH，但必须重启终端或新开 PowerShell 才能读到；macOS/Linux 用 tar -C /usr/local -xzf go*.tar.gz 解压后，/usr/local/go/bin 必须手动加进 shell 配置文件（如 ~/.zshrc），然后运行 source ~/.zshrc。
验证方式很简单：
- macOS/Linux：运行
which go，有输出才算成功 - Windows：在 PowerShell 里运行
Get-Command go，不是靠 cmd 里的where go—— PowerShell 的 PATH 解析更准 - 别信安装界面勾选的“Add to PATH”，它只对当前会话有效，重启终端后就失效
GOROOT 和 GOPATH 还要配吗？基本不用
Go 1.16+ 默认启用模块模式（GO111MODULE=on），GOROOT 由 go 自动推导，只要 go 命令能跑，就不需要手动设；GOBIN 也同理——除非你明确要把 go install 生成的二进制放别处，否则留空即可。
GOPATH 更是彻底退居二线：它只影响 go get 旧式路径解析和 go install 默认输出位置，新项目完全不依赖它。如果你没用 vendor/、没跑老脚本、没在 $GOPATH/src 下建项目，那 GOPATH 可以完全不管。
真正要做的只有两件事：
- 确保
go命令可用（PATH 正确） - 新建项目时直接
mkdir hello && cd hello && go mod init hello，别管目录在哪
VS Code 里 gopls 启动失败？先查三个硬性前提
gopls 不是插件装上就跑，它是个独立进程，启动失败往往卡在底层依赖上。最常踩的坑是：
-
go命令不可用：VS Code 终端能跑go version，不代表编辑器内部能调用——检查 VS Code 的集成终端是否用了正确 shell（比如 macOS 上 VS Code 默认用 zsh，但你改过~/.bash_profile） - 项目根目录下没有
go.mod：gopls要求至少存在一个合法模块，go mod init必须成功执行过，且不能在$GOPATH/src下执行（否则会生成错误 module path） - 文件后缀不对：VS Code 只对
.go文件激活gopls，如果文件叫main没后缀，或者误存为main.golang，语言服务器根本不会启动
代理配置要不要加？国内开发建议加
不配 GOPROXY 也能跑 go mod download，但默认源 https://proxy.golang.org 在国内大概率超时或 403。这不是“加速”问题，是“能不能下载”的问题。
一行命令就能设好：
- PowerShell：
go env -w GOPROXY=https://goproxy.cn,direct - bash/zsh：
go env -w GOPROXY=https://goproxy.cn,direct
direct 是关键——它表示当模块在代理里找不到时，回退到直接从源仓库拉（比如私有 git repo）。别写成 https://goproxy.cn 单独一个值，否则私有模块会失败。
这个配置只影响 go mod download 和 go get，不影响 go run 或编译速度，也不影响本地开发流程，属于“配了省心，不配卡顿”的刚需项。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
