go mod download 反复卡在变动依赖上是因为 go 默认每次重新校验远程元数据，尤其对 pseudo-version 依赖；可通过 goproxy/gonoproxy 分级代理、vendor 固化或 replace 本地路径解决。
为什么 go mod download 会反复卡在变动依赖上
模块版本频繁更新（比如 main 分支、dev 标签、未打 tag 的 commit）时，Go 默认每次都会重新校验远程元数据，即使本地已有缓存。这不是网络慢，而是 Go 工具链主动绕过缓存去查最新 @v/list 或 @v/vX.Y.Z.info，尤其当 go.mod 里写的是 github.com/user/repo v0.0.0-20240101000000-abc123 这类 pseudo-version 时更明显。
用 GOPROXY + GONOPROXY 精准控制静态代理策略
变动依赖常来自两类源：公开仓库的不稳定分支（如 GitHub 上的 main），或公司内网 Git 的 daily build 分支。不能全走代理，也不能全禁用——得按域名分级处理：
-
GOPROXY=https://goproxy.cn,direct是基础，但对高频变动源不够稳 - 把明确知道“只读、不更新”的公开模块加进
GONOPROXY，强制复用本地缓存：go env -w GONOPROXY="github.com/grpc-ecosystem/grpc-gateway,github.com/uber-go/zap" - 把内网 Git 域名也加进去：
go env -w GONOPROXY="git.internal.company.com,gitlab.example.org" - 注意：
GONOPROXY和GONOSUMDB必须值完全一致，否则 checksum 校验失败
预下载 + vendor 目录固化高频变动依赖
如果项目中几个模块每周都变（比如自研的 SDK、内部工具库），靠缓存不如直接固化：
- 执行
go mod vendor将所有依赖（含变动模块）复制到vendor/目录 - 后续构建加
-mod=vendor参数：go build -mod=vendor，完全跳过网络和代理逻辑 - CI/CD 中可结合
go mod download预热缓存：go mod download && go mod vendor，避免每次构建都拉一次 - 注意：
vendor不会自动更新，改了go.mod后需手动再运行go mod vendor
用 replace 指向本地副本，彻底脱离网络波动
对真正“天天变”的模块（如正在联调的 proto 生成库、灰度中的中间件），最稳的方式是本地托管：
- 把模块 clone 到本地路径，比如
~/go-local/my-sdk - 在
go.mod里加replace github.com/company/my-sdk => ../go-local/my-sdk - 此时
go build完全不发起任何 HTTP 请求，也不查GOPROXY - 缺点：团队协作时需同步本地路径，可用
replace github.com/company/my-sdk => ./local/my-sdk放进 repo，并加.gitignore排除内容
真正容易被忽略的是：GONOPROXY 不支持通配符前缀匹配（如 github.com/company/* 只在 Go 1.19+ 支持），旧版本必须列全域名；另外 replace 路径若含空格或中文，会导致 go mod tidy 报错，务必用纯英文路径。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
