根本原因是goproxy未生效或配置错误，需设为https://goproxy.cn,direct（含,direct兜底），并确认go env goproxy输出正确；同时应显式配置gomodcache以复用本地缓存。
go version 能跑，但 go get 总超时或失败
根本原因不是网络差，而是 GOPROXY 没生效或配置错误。Go 1.13+ 默认启用代理，但国内直连 proxy.golang.org 基本不可用。
- 执行
go env -w GOPROXY=https://goproxy.cn,direct（推荐）或https://mirrors.aliyun.com/goproxy/,direct -
direct是关键：对私有域名（如git.internal.company）跳过代理，避免内网依赖拉取失败 - 验证是否生效：
go env GOPROXY必须输出你刚设的地址，不是空或默认值 - 如果公司有私有镜像源，把
https://goproxy.cn替换成你们内部地址即可
go mod download 很慢，甚至反复下载同一模块
不是网速问题，是本地缓存没被复用。Go 的模块缓存路径默认在 $GOPATH/pkg/mod，但如果你没设 GOPATH 或用了非标准路径，缓存可能分散或失效。
- 先确认缓存位置：
go env GOMODCACHE，它通常等于$GOPATH/pkg/mod - 如果输出为空或指向 C 盘（如
C:\Users\xxx\go\pkg\mod），建议显式设置：go env -w GOMODCACHE=E:\go\modcache - 首次运行
go mod download后，所有依赖会解压到该目录；后续构建不再走网络，除非版本变更 - 别手动删
pkg/mod下的子目录——用go clean -modcache清理，否则可能破坏完整性
项目里 go run 正常，CI 构建却反复拉包
CI 环境通常没有持久化缓存，每次都是干净环境，go mod download 变成全量重拉。
- Docker 构建时，在
Dockerfile中提前执行go mod download，并确保GOMODCACHE被挂载为 volume - GitHub Actions 中用
actions/cache@v4缓存~/go/pkg/mod，key 建议包含go.mod的 hash - 团队共用开发机时，可统一配置
GOMODCACHE到 NFS 共享路径，避免每人一份重复缓存 - 注意：
go build -o xxx不触发下载，但go test或go list可能触发，CI 脚本里应显式加go mod download预热
GOCACHE 和 GOMODCACHE 容易混淆
两者完全独立：GOCACHE 存编译中间产物（如 .a 文件），GOMODCACHE 存下载的模块源码。一个影响构建速度，一个影响依赖获取速度。
-
GOCACHE默认在系统临时目录（Windows 是%LocalAppData%\go-build），占空间大，建议移到非系统盘：go env -w GOCACHE=E:\go\buildcache -
GOMODCACHE一旦设好，所有go命令自动使用，无需额外参数 - 检查是否生效：运行
go build -x，看输出里WORK=路径是否指向你设的GOCACHE；运行go list -m -f '{{.Dir}}' std看是否指向GOMODCACHE - 二者都设好后，
go build第二次执行几乎秒出，因为既不用重新下载模块，也不用重编译未变代码
GOPROXY 的 ,direct 后缀和 GOMODCACHE 的显式配置。没这两项，所谓“本地缓存”基本形同虚设。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
