go mod download 慢的根本原因是默认代理 proxy.golang.org 国内不可达，且未正确配置 GOPROXY 与 GOSUMDB 导致反复校验超时；需设为 goproxy.cn 并确保二者同源，同时配置 GOPRIVATE 处理私有模块。
为什么 go mod download 总是慢得像在等编译完成？
根本原因不是网络差，而是默认走官方代理 proxy.golang.org（国内不可达），且不校验缓存有效性时会反复请求远程 checksum 数据。Go 1.18+ 默认启用 GOPROXY，但若环境变量未显式设置或被覆盖，go 命令会退回到直连 module server 或尝试 direct 模式，触发大量超时重试。
- 检查当前生效的代理：
go env GOPROXY - 确认是否被 shell 配置（如
.zshrc）或 IDE 的环境变量覆盖 -
go list -m all卡住时，加-v可看到具体卡在哪一步（常是https://sum.golang.org/lookup/...）
国内可用的稳定代理与正确配置方式
必须同时设置模块代理和校验服务器，否则 go mod verify 会失败或降级为直连。推荐组合：
export GOPROXY=https://goproxy.cn,direct export GOSUMDB=gosum.io+ce6e7565+https://goproxy.cn/sumdb
注意：direct 是 fallback 关键字，表示对私有模块（如公司内网域名）跳过代理；GOSUMDB 的 URL 必须与 GOPROXY 同源，否则校验失败报错 checksum mismatch。
- 临时测试：运行
GOPROXY=https://goproxy.cn GOSUMDB=gosum.io+ce6e7565+https://goproxy.cn/sumdb go mod download - 永久生效：写入 shell 配置后执行
source ~/.zshrc，再验证go env GOPROXY GOSUMDB - 若用
github.com私有仓库，需额外加GOPRIVATE=github.com/my-org/*
go mod download 缓存机制与手动清理时机
Go 模块缓存在 $GOPATH/pkg/mod（或 $GOMODCACHE 指向路径），但缓存命中依赖 go.sum 中的哈希值。一旦 go.sum 被修改、删除或校验失败，go 工具链会重新下载并校验，而非复用磁盘文件。
git-staged-commit-message
下载
仅从仓库的暂存文件生成 Git 提交消息。当用户要求 Codex 根据暂存更改、缓存差异、Git 索引或已通过 `git add` 添加的文件来编写、起草、创建或建议提交消息时使用；切勿代表用户执行提交操作。
立即学习“go语言免费学习笔记（深入）”；
- 查看缓存位置：
go env GOMODCACHE - 安全清理旧模块：
go clean -modcache（慎用，会清空全部缓存） - 精准清理某模块：
rm -rf $(go env GOMODCACHE)/github.com/sirupsen/logrus@v1.9.0 - 避免误删：缓存中
@vX.Y.Z目录名含版本号，不含+incompatible后缀的才是标准语义化版本
CI/CD 中加速模块加载的关键点
CI 环境通常无持久缓存，每次构建都从零下载。光设代理不够，必须复用 GOMODCACHE 目录。
- GitHub Actions 示例：用
actions/cache缓存${{ env.HOME }}/go/pkg/mod - GitLab CI：在
cache:下添加key: $CI_PROJECT_NAME-go-mod-cache和paths: ["/root/go/pkg/mod"] - 自建 runner：挂载宿主机目录到容器内
/root/go/pkg/mod，比网络代理提速更显著 - 禁止在 CI 中用
go get -u，它会强制刷新所有依赖，破坏缓存稳定性
真正影响速度的从来不是带宽，而是重试逻辑和校验路径。只要 GOPROXY 和 GOSUMDB 对齐、缓存目录可复用、私有模块标记正确，go mod download 就不会反复拉取同一版本。
