go命令响应慢的根本原因是goproxy、go111module和gosumdb三者未对齐：必须设go111module=on启用模块模式，goproxy=https://goproxy.cn,direct实现代理 fallback，gosumdb=sum.golang.google.cn避免校验卡死。
go 命令响应慢，不是环境没搭好，而是代理、模块、缓存三者没对齐。核心问题往往出在 GOPROXY 和 GO111MODULE 的组合行为上，尤其在国内网络环境下。
为什么 go mod download 卡住或超时
常见现象是执行 go run、go build 或 go mod tidy 时卡在 “Downloading” 或直接报 Get \"https://proxy.golang.org/...\": dial tcp: i/o timeout。
根本原因：Go 默认使用 https://proxy.golang.org（被墙），且当 GO111MODULE=on 时，所有依赖都强制走模块代理——哪怕本地有缓存，也会先尝试连代理校验 checksum。
-
GO111MODULE=auto在非 module 目录下会退化为 GOPATH 模式，但现代项目基本不适用 -
GOPROXY=direct表示跳过代理直连，等同于裸连 goproxy.org，国内基本不可用 - 只设
GOPROXY不设GOSUMDB，会导致 checksum 校验阶段仍连国外服务器失败
必须同时配置的三项环境变量
缺一不可，否则任一环节断链都会拖慢整个命令响应：
-
GO111MODULE=on：启用模块模式（强制要求） -
GOPROXY=https://goproxy.cn,direct：优先走国内镜像，失败才 fallback 到 direct（注意逗号后无空格） -
GOSUMDB=sum.golang.google.cn：校验数据库也切到国内源，避免 checksum 阶段卡死
PowerShell 示例：
go env -w GO111MODULE=on go env -w GOPROXY=https://goproxy.cn,direct go env -w GOSUMDB=sum.golang.google.cn
验证是否生效：go env | grep -E 'GO111MODULE|GOPROXY|GOSUMDB' 应全部命中对应值。
VS Code 中 go extension 响应慢的隐藏原因
即使终端里 go 命令很快，VS Code 编辑器内 hover 提示、自动补全、保存格式化仍可能延迟数秒——这通常不是 Go 本身的问题，而是 gopls（Go language server）启动时重复触发了模块下载。
-
gopls启动默认会调用go list -m all，若项目go.mod有未缓存的依赖，就会现场拉取 - 解决方法：在项目根目录手动预热一次
go mod download，让依赖落地到本地$GOPATH/pkg/mod/cache - 额外建议：在 VS Code
settings.json中加"go.toolsEnvVars": { "GOMODCACHE": "/path/to/fast/ssd/go/pkg/mod" }，把模块缓存移到 SSD 路径，减少 IO 瓶颈
首次 go run 仍然慢？检查 GOROOT 是否被污染
某些旧版安装或手动解压方式会导致 GOROOT 指向一个未编译的源码目录（比如 /usr/local/go/src），此时每次运行都要重新构建标准库，耗时可达 10+ 秒。
正确做法是确认 GOROOT 指向二进制安装路径（如 /usr/local/go 或 C:\Program Files\Go），而非 src 子目录。执行 go env GOROOT 查看，若输出含 src，立刻用 go env -w GOROOT=/usr/local/go 修正。
这个点容易被忽略：它不报错，但会让所有命令首启变慢，且不会在任何日志里提示“我在重编译 runtime”。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
