go环境真正可用需同时满足go version可执行且go env goproxy返回国内镜像地址；path缺失$goroot/bin或$gopath/bin、go111module未强制设为on、goproxy未配,direct fallback，均会导致go mod tidy卡住或gopls启动失败。
Go 环境能跑 go version 且 go env GOPROXY 返回国内镜像地址，才算真正可用；其余配置错一半都可能卡在 go mod tidy 或 gopls 启动失败上。
go version 报“不是内部或外部命令”？立刻查 PATH 里有没有 $GOROOT/bin
Windows 用户装完 .msi 却仍报错，大概率是没重启 CMD/PowerShell——旧终端不读新环境变量。macOS/Linux 手动解压 tar.gz 后只设了 GOROOT，却忘了把 $GOROOT/bin 加进 PATH。
- Windows：运行
echo %PATH%，确认输出中含类似C:\Program Files\Go\bin或你自定义的安装路径下的\bin - macOS/Linux：运行
echo $PATH，检查是否含/usr/local/go/bin（默认）或你设的$GOROOT/bin - 别信“安装包自动配好了”——手动验证才是唯一可靠方式
go mod tidy 卡住、超时、fetching dependencies 失败？GO111MODULE 和 GOPROXY 必须同时生效
Go 1.16+ 默认开启模块模式，但若 GO111MODULE=auto（旧 shell 遗留值）或 GOPROXY 为空，go mod 就会直连 proxy.golang.org，国内基本不可用。
- 执行
go env -w GO111MODULE=on强制启用模块模式 - 执行
go env -w GOPROXY=https://goproxy.cn,direct（中科大、七牛云也可，但goproxy.cn稳定性实测更优） - 验证：运行
go env GOPROXY和go env GO111MODULE，两个都必须返回对应值，不能是空或auto
VS Code 打开 Go 文件后没补全、跳转失效、底部一直显示 “gopls: indexing”？别乱填 go.goroot 和 go.gopath
VS Code 的 Go 扩展（golang.go）会自动探测 GOROOT 和 GOPATH。手动在 .vscode/settings.json 里写死路径，反而会导致 gopls 初始化失败或加载错误 workspace。
- 删掉
"go.goroot"和"go.gopath"这两项配置，留空或直接移除 - 确保
"go.useLanguageServer": true已启用（这是补全、诊断、跳转的底层依赖） - 首次打开项目时耐心等——
gopls需要索引整个 module，状态栏从indexing变成ready才算就绪；强行关窗口会导致缓存损坏，重开后更慢
go install 编译的工具（如 dlv、gofumpt）找不到命令？$GOPATH/bin 必须在 PATH 中
go install 默认把二进制放到 $GOPATH/bin，而不是当前目录或 $GOROOT/bin。如果这个路径没进 PATH，终端就无法直接调用 dlv 或 gofumpt，VS Code 的 Go 扩展也会提示 “tool not found”。
- Windows：在系统环境变量
Path中追加%GOPATH%\bin（注意不是%GOROOT%\bin） - macOS/Linux：在
~/.zshrc或~/.bash_profile中添加export PATH=$PATH:$GOPATH/bin - 改完记得
source ~/.zshrc或重启终端，再运行which dlv或dlv version验证
真正卡住人的从来不是安装步骤，而是 go env 输出和实际终端行为不一致——比如 go env GOPROXY 显示正确，但 go mod download 仍走国外源，说明 shell 会话没继承到最新环境变量，或者用了不同 shell（zsh vs bash vs fish）导致配置文件没被读取。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
