Go命令找不到、go mod init静默失败、gopls启动报错，90%源于PATH加载时机错误或GOPATH/src路径干扰：需验证which go、确认不在$GOPATH/src下、确保go.mod存在且gopls依赖的go命令全局可用。
Go 命令找不到、go mod init 静默失败、VS Code 里 gopls 启动报错——这些问题不是环境“没装好”，而是 PATH、模块模式、项目路径三者之间没对齐。核心判断：90% 的报错根源在环境变量加载时机或 GOPATH/src 路径干扰。
go command not found 的真实原因和验证步骤
安装包点完“完成”不等于终端能用 go，本质是 shell 没读到新 PATH。Windows 用户容易忽略 PowerShell 和 CMD 的环境变量隔离；macOS/Linux 用户常误以为 ~/.bashrc 改了就立即生效。
- Windows：别只信 CMD，用 PowerShell 运行
Get-Command go；若失败，去「系统属性 → 高级 → 环境变量」确认C:\Program Files\Go\bin（或自定义路径）确实在用户或系统 PATH 中 - macOS/Linux：新开一个终端，执行
which go；没输出？检查你改的是~/.zshrc还是~/.bash_profile（macOS Catalina+ 默认用 zsh），然后手动source ~/.zshrc - 别依赖安装器勾选的“添加到 PATH”——它只对后续新建终端生效，旧终端必须重启或
source
go mod init 失败却没报错，其实是被 GOPATH/src 绑架了
go mod init 在 $GOPATH/src 下运行时，会强行按旧 GOPATH 规则推导 module 名（比如 github.com/xxx/yyy），而不是你期望的 example.com/project，且不提示警告。
- 先运行
pwd确认当前目录不在$GOPATH/src或$GOROOT/src内；如果在，cd到任意其他路径再试 - 删掉项目根目录下的
vendor/目录（除非你明确要 vendor） - 执行
go env -w GO111MODULE=on强制启用模块模式（Go 1.16+ 默认开启，但 CI 或老脚本可能关着） - 确保当前目录下没有
go.mod，否则go mod init会跳过
VS Code 里 gopls 启动失败的三个硬性前提
gopls 不是插件装上就行，它是个独立进程，启动失败基本卡在这三个条件之一没满足：
立即学习“go语言免费学习笔记（深入）”；
-
go命令必须全局可用：终端里能跑go version，VS Code 的集成终端也得能——某些远程开发场景下，VS Code 可能没加载你的 shell 配置 - 项目根目录必须有
go.mod：哪怕只是空文件，gopls才会识别为 Go module 项目；没它就当普通文本处理 - 文件后缀必须是
.go：VS Code 的 Go 插件靠后缀激活语言服务器，.txt或无后缀文件不会触发gopls
GOPROXY 和 GOPATH 设置的常见副作用
设了 GOPROXY 能解决依赖拉取慢，但设错会导致 go install 工具失败；GOPATH 不设或设错则影响 go install 生成的二进制存放位置。
-
go env -w GOPROXY=https://goproxy.cn,direct（国内推荐）；别漏掉,direct，否则私有模块无法 fallback - Go 1.21+ 已弱化
GOPATH依赖，但go install默认把可执行文件放$GOPATH/bin；如果你没设GOPATH，它会用默认值$HOME/go，而该路径可能没加进PATH，导致命令找不到 - 不要把
GOPATH设成$GOROOT—— 这会导致go get报cannot find package "." in ...，因为 Go 会拒绝在安装目录里写代码
真正麻烦的不是装 Go，而是不同安装方式（.msi/.pkg/tar.gz/apt）对环境变量的写入逻辑完全不同，且 shell 加载顺序、终端类型、IDE 启动方式都会干扰 PATH 生效。验证时永远用新开终端 + which go + go env GOROOT GOPATH 三连，比反复重装更省时间。
