必须配GOPROXY，因为Go 1.11+默认启用Modules后，go mod download直连不可用的proxy.golang.org，导致超时或解析失败；国内应配置goproxy.cn或mirrors.aliyun.com/goproxy/并加,direct后缀以支持私有模块。
为什么必须配 GOPROXY，不配就卡在 go mod download
Go 1.11 后默认启用 Go Modules，go mod download 会直接从互联网拉取依赖，但官方 proxy.golang.org 在国内基本不可用。不配代理时，常见现象是命令卡住几十秒后报错：proxy.golang.org: no such host 或 timeout，甚至触发 go: github.com/xxx: Get "https://proxy.golang.org/...": dial tcp: i/o timeout。这不是你网络差，而是直连失败的必然结果。
- 国内可用且稳定的是
https://goproxy.cn（七牛云）和https://mirrors.aliyun.com/goproxy/（阿里云） - 必须加
,direct后缀，否则私有模块（如公司内网 Git 地址）无法绕过代理直连 - 配置方式统一用
go env -w GOPROXY=...，不要手动改系统环境变量——Go 会优先读取go env的值，手动改 PATH 或用户变量容易冲突
GO111MODULE=on 是默认值，但老项目或 GOPATH 模式下仍需显式开启
Go 1.16+ 已默认开启模块模式，但如果你在旧项目里执行 go build 却发现它还在往 $GOPATH/src 里找包，说明当前目录没 go.mod，且 GO111MODULE 被意外设为 auto 或 off。这时 go mod init 会失败，go get 也走不了模块路径。
- 执行
go env -w GO111MODULE=on强制启用，避免隐式 GOPATH 行为 - 如果项目已有
go.mod，但go list -m all报错说 “not in a module”，大概率是 shell 当前工作目录不在模块根目录下 - Windows 用户注意：PowerShell 和 CMD 对
go env -w的解析一致，但某些老旧终端可能缓存旧值，建议重启终端再验证
GOROOT 和 GOPATH 现在怎么设才不踩坑
Go 1.16+ 不再强制依赖 GOPATH，但 VS Code 的 Go 插件、go install 命令、以及部分工具链（如 dlv）仍会读取它来定位 bin 工具。乱设 GOPATH 最典型的问题是：插件提示“Go tools not installed”，点 Install All 却反复失败，或者 go install 生成的二进制找不到。
-
GOROOT应指向 Go 安装根目录（如 Windows 是C:\Go，macOS 是/usr/local/go），安装器通常已自动写入，不用手改 -
GOPATH推荐保持默认（$HOME/go），只用于存放go install生成的可执行文件；不要把它设成项目目录，否则go mod可能误判为 GOPATH 模式 - VS Code 中若提示工具缺失，先运行
go install golang.org/x/tools/gopls@latest，再检查$GOPATH/bin是否在系统PATH里
代理配置生效后，如何快速验证是否真通了
别只信 go env | findstr GOPROXY 输出，那只是配置写进去了，不代表能连上。真正验证得看实际下载行为。
立即学习“go语言免费学习笔记（深入）”；
- 新建空目录，执行
go mod init testmod→go get github.com/sirupsen/logrus@v1.9.0，成功则说明代理通且模块解析正常 - 如果报
verifying github.com/...: checksum mismatch，不是代理问题，而是本地缓存损坏，删掉$GOCACHE目录重试 - 想看详细请求过程？加
-v参数：go get -v github.com/...，会打印每一步 fetch 和 verify 日志，代理地址是否被正确使用一目了然
go 命令解析模块路径，到发起 HTTPS 请求，再到校验 checksum，任何一环断开都会表现为“下载失败”。最常被忽略的是 ,direct 后缀缺失导致私有模块挂掉，以及 GOPATH/bin 不在 PATH 导致工具链失效——这两处出问题，连代码补全都出不来。 
