go env -w 配置重启终端失效，因其仅修改 Go 内部 env 文件，不覆盖 shell 启动时加载的同名环境变量；持久化需在 shell 配置文件或系统环境变量中设置，并通过 echo $GOPROXY 验证真实生效值。
go env -w 写入的配置为什么重启终端就失效？
因为 go env -w 修改的是 Go 的内部配置（存储在 %USERPROFILE\AppData\Roaming\go\env 或 $HOME/go/env），但它不覆盖 shell 启动时加载的环境变量。如果 shell 中已通过 export GOPROXY=... 设置了同名变量，它会优先于 go env 的值——尤其在 VS Code 终端、JetBrains IDE 内置终端中常见。
真正持久化，必须让 shell 自己加载配置。Windows 用户别只依赖安装程序自动设的 Path，macOS/Linux 用户别只改 ~/.bashrc 却忘了 zsh 默认读 ~/.zshrc。
- Windows：用「系统属性 → 高级 → 环境变量」面板设置系统级变量，或在 PowerShell 的
$PROFILE里追加[System.Environment]::SetEnvironmentVariable('GOPROXY', 'https://goproxy.cn,direct', 'User') - macOS/Linux：确认当前 shell 类型（
echo $SHELL），然后编辑对应文件（~/.zshrc或~/.bash_profile），添加export GOPROXY=https://goproxy.cn,direct和export GO111MODULE=on - 验证方式不是
go env GOPROXY，而是echo $GOPROXY—— 这才反映真实生效的 shell 环境变量
GOROOT 和 GOPATH 还需要手动设吗？
GOROOT 大概率不用设：官方 MSI 或 .pkg 安装包会自动写入正确路径；手动解压二进制包才需显式设置 GOROOT。但 GOPATH 建议保留默认值（~/go 或 C:\Users\xxx\go），不是为了 src 目录，而是因为 gopls、dlv、go install 生成的二进制都默认落进 $GOPATH/bin，删掉它会导致命令找不到。
关键点在于：Go Modules 启用后，GOPATH 不再决定项目位置，但仍是工具链的“家目录”。如果你把 GOBIN 单独设为 ~/bin，就得确保它也在 PATH 里，否则 go install 出的命令无法直接运行。
立即学习“go语言免费学习笔记（深入）”；
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 不要把项目放
$GOPATH/src下再go build——这会意外触发 GOPATH 模式，绕过go.mod -
go clean -modcache比手动删$GOPATH/pkg/mod更安全，避免破坏缓存索引 - VS Code 的 Go 扩展会读
go env GOROOT，但 GoLand 需在 Settings → Go → GOROOT 点击 “Reload” 才更新
VS Code settings.json 里哪些配置能替代环境变量？
settings.json 中的 "go.toolsEnvVars" 是唯一能可靠覆盖 shell 环境的地方，尤其对 gopls 启动生效。它比全局 export 更精准，适用于多项目不同代理策略的场景（比如一个项目走私有代理，另一个走 goproxy.cn）。
但注意：这个字段只影响 Go 工具链（gopls、goimports 等），不影响你在终端里手动执行的 go build 命令——后者仍取决于 shell 环境。
- 推荐写法：
"go.toolsEnvVars": { "GOPROXY": "https://goproxy.cn,direct", "GOPRIVATE": "git.example.com/*" } -
"go.goroot"和"go.gopath"只在 VS Code 无法自动探测时才需显式填写，填错会导致插件报 “Go binary not found” - 若启用了
"go.useLanguageServer": true，所有代码跳转、补全都依赖gopls，而gopls启动失败往往就是GOPROXY或GOROOT没传进去
为什么 go mod download 卡住，但 go env 显示代理已配置？
最常见原因是 GOPROXY 值里漏了 direct。例如设成 https://goproxy.cn 而非 https://goproxy.cn,direct，当遇到私有模块或本地 replace 路径时，goproxy.cn 无法回源，又没 fallback 到直连，就无限等待。
另一个隐蔽坑是：某些公司网络会拦截 HTTPS 请求并替换证书，导致 goproxy.cn 的 TLS 握手失败。此时 go mod download 表现为超时，但 curl -v https://goproxy.cn 却能通——本质是 Go 的 net/http 默认校验证书链，而 curl 可能被配置为忽略。
- 验证代理是否真生效：
go mod download github.com/spf13/cobra@v1.8.0，几秒内完成才算成功 - 调试时加
-x参数：go mod download -x github.com/spf13/cobra，看实际请求发到了哪个 URL - 临时禁用代理测试：
GOPROXY=direct go mod download，如果成功，说明代理服务本身或网络策略有问题
