go mod download卡在git clone阶段是因为Go直接调用系统git命令拉取私有或未代理模块，当GitHub等源不可达时即中断；应优先用replace重定向或配置GOPROXY="https://goproxy.cn,direct"并设GOPRIVATE排除私有域名。
为什么 go mod download 会卡在 git clone 阶段？
Go 模块拉取失败时，常见现象是命令卡住几秒后报错：fatal: unable to access 'https://github.com/xxx/yyy/': Failed to connect to github.com port 443: Connection refused 或类似提示。这不是 Go 工具链问题，而是 go mod download 在解析 go.mod 后，直接调用系统 git 命令克隆远端仓库 —— 如果 GitHub、GitLab 或私有 Git 服务正在维护或网络不通，整个依赖拉取就中断。
用 replace 临时指向本地或镜像路径
最快速绕过远端 Git 故障的方式，是在项目根目录的 go.mod 中插入 replace 指令，把出问题的模块重定向到可用源：
replace github.com/sirupsen/logrus => ./vendor/github.com/sirupsen/logrus
或者指向国内镜像（需确保镜像已同步且版本匹配）：
replace github.com/spf13/cobra => github.com.cnpmjs.org/spf13/cobra v1.8.0
注意：replace 不会自动下载目标路径内容，你得提前准备好本地副本或确认镜像 tag 存在；执行后需运行 go mod tidy 触发重新解析。
立即学习“go语言免费学习笔记（深入）”；
-
replace只影响当前 module，不影响子依赖的间接引用（除非也显式 replace） - 若被 replace 的模块本身有 submodules 或
//go:embed路径，本地路径必须保留完整目录结构 - 上线前务必删掉
replace行，否则构建环境可能因缺失本地路径而失败
启用 GOPROXY 并配置 fallback 代理链
Go 1.13+ 默认启用代理模式，但单点代理（如 https://proxy.golang.org）挂了也会失败。推荐配置多级 fallback：
export GOPROXY="https://goproxy.cn,direct"
或更稳妥写法（含私有仓库白名单）：
export GOPROXY="https://goproxy.cn,https://proxy.golang.org,direct"
其中 direct 是兜底项：当所有代理都返回 404 或 502 时，才回退到直连 git。但要注意：
- 某些企业内网禁止直连外网 git，此时
direct会导致失败，应替换为内部 Git 代理地址 -
GOPROXY不影响replace和exclude指令，它们优先级更高 - 私有模块（如
git.example.com/internal/pkg）默认不走 proxy，需额外设置GOPRIVATE=git.example.com/*
缓存已有模块避免重复拉取
即使远端恢复，频繁 go mod download 仍可能触发限流或超时。建议在 CI/CD 或本地开发机上复用 $GOPATH/pkg/mod/cache：
- 确认
GOENV未覆盖默认缓存路径，可用go env GOCACHE查看 - CI 中挂载缓存目录（如 GitHub Actions 的
actions/cache），key 包含go.sumhash 更可靠 - 手动清理损坏缓存：运行
go clean -modcache，但会强制重拉全部依赖 —— 仅在 checksum mismatch 错误时使用
真正麻烦的不是某次拉取失败，而是不同环境对同一模块用了不同 commit 或 tag —— 这会让 go.sum 校验失败。所以只要远端 Git 不可用，就得靠 replace 或可信 proxy 控制源头，而不是靠 retry 或调大 timeout。
