go mod download卡在proxy.golang.org超时是因国内直连代理失败，应设GOPROXY=https://goproxy.cn,direct并配GOSUMDB=off（测试）或sum.golang.org（生产），私有模块需GONOPROXY，校验失败先清缓存go clean -modcache。
go mod download卡在proxy.golang.org超时
这不是 Go 安装失败，而是模块下载阶段网络不通。Go 1.13+ 默认用 proxy.golang.org，内网或国内直连基本都会卡住，现象是命令无响应、几秒后报 connection refused 或直接 hang 住。
临时验证是否代理问题：执行 go env -w GOPROXY=direct，再跑 go mod download——若仍失败，说明连源码仓库（如 GitHub）也访问不了，direct 模式无效。
- 生产环境别长期用
direct：它绕过代理但不解决校验问题，GOSUMDB仍会尝试连sum.golang.org，导致go build失败 - 推荐组合设置：
go env -w GOPROXY=https://goproxy.cn,direct+go env -w GOSUMDB=off（测试环境）或go env -w GOSUMDB=sum.golang.org（生产环境配可信代理） -
GOPROXY中必须包含,direct，否则私有模块（如gitlab.internal）会因无法回退而报403或module not found
GOPROXY 设置后仍报 checksum mismatch
现象是 verifying github.com/xxx@v1.2.3: checksum mismatch，本质不是代码被篡改，而是本地缓存、镜像同步延迟或 replace 规则冲突导致的校验失败。
- 先清缓存：
go clean -modcache，再重试go mod download；这能解决 70% 的误报 - 检查
go.mod里是否有replace指向本地路径但没删// indirect标记——这种残留会让 Go 误算校验和 - 临时绕过单个模块校验：
go get -insecure github.com/xxx/yyy，但别设全局GOINSECURE，否则私有域名全跳过校验，风险不可控
CI 构建或 vendor 后仍校验远程 sum
go mod vendor 成功不代表构建就稳了。默认情况下，即使有 vendor 目录，Go 仍会连接远程校验服务器，除非显式禁用。
立即学习“go语言免费学习笔记（深入）”；
- CI 构建机必须设：
GOPROXY=direct+GOSUMDB=off，再运行go build；只设GOPROXY不够 -
go mod vendor前务必先go mod tidy，否则vendor里可能混入已删模块，构建时触发校验逻辑 - 若用私有代理（如 Athens），需确保
GOSUMDB指向同域的校验服务（如https://goproxy.internal.company/sum），否则代理能拉代码、校验服务连不上，照样失败
VS Code 插件或 go install 工具拉取失败
VS Code 的 Go 扩展、gopls、dlv 等工具安装失败，常因 go install 绕过 GOPROXY 直连 golang.org/x/ 路径导致。
- 改用
GO111MODULE=on go install golang.org/x/tools/gopls@latest（Go 1.16+ 推荐方式） - 若仍超时，手动替换路径：
github.com/golang/tools替代golang.org/x/tools（仅调试用，需同步改 import） - 更稳妥做法：配好
GOPROXY后，加go env -w GONOPROXY="gitlab.example.com,192.168.0.0/16"，避免私有域名也被代理 - IDE 内环境变量未继承 shell 配置是常见静默失败原因，VS Code 需在设置中显式配置
go.toolsEnvVars
GOPROXY 和 GOSUMDB 必须协同生效，,direct 不能漏，GONOPROXY 要覆盖所有私有域，而 IDE 是否读取了你设的环境变量，往往比命令行更难察觉。 
