根本原因是go解析依赖时遇到无效的replace或require引用，如不存在的commit、私有路径或已删tag，导致代理无法解析而反复重试、超时甚至卡死在checksum mismatch或静默hang住。
为什么 go mod download 会卡在某个包上不动？
根本原因不是网络慢，而是 Go 在解析依赖时遇到了 replace 或 require 中指向不存在的 commit、私有路径、或已被删除的 tag。Go 模块代理（如 proxy.golang.org）无法解析这些引用，就会反复重试、超时、退回到直接 fetch，最终卡死在 verifying github.com/xxx/yyy@v1.2.3: checksum mismatch 或静默 hang 住。
检查并清理失效的 replace 和 indirect 引用
很多项目长期维护后，go.mod 里残留了早已废弃的 replace 规则，或者 require 里带 // indirect 的包实际已不被任何代码 import，却仍被 Go 拉取验证。
- 运行
go mod graph | grep -E 'your-broken-package|github.com/xxx'查看谁在间接依赖它 - 执行
go mod edit -dropreplace github.com/xxx/yyy删除明确失效的 replace - 用
go mod vendor && go list -m all | grep indirect结合代码扫描，确认哪些indirect包真没被用到，再go mod tidy清理 - 特别注意：某些 replace 指向本地路径（如
./local-fork），CI 环境下必然失败，必须改成 git URL 或临时注释掉
绕过校验失败但保留依赖结构的临时方案
当确认某个包确实无法修复（比如上游删库、私有模块无权限），又不能删掉整个依赖链时，可让 Go 跳过 checksum 校验，但仅限开发调试，不可用于生产构建。
- 设置环境变量：
GOSUMDB=off（禁用校验）或GOSUMDB=sum.golang.org+insecure（允许 insecure 源） - 配合
go env -w GOPROXY=direct强制直连，避免代理缓存脏数据 - 若只针对单个模块跳过校验，可在
go.mod中加// +insecure注释行（Go 1.21+ 支持），但需确保该模块确实可信 - 注意：
GOSUMDB=off不影响go build，但go mod download和go mod verify会跳过所有校验，慎用
替换不可靠的私有模块为 fork + tag 可控版本
最稳妥的解法不是绕过问题，而是接管不可控依赖。尤其当原仓库已归档、作者失联、或使用未打 tag 的 commit 时。
- fork 到你自己的 GitHub/GitLab，保证 repo 存活且可读
- 在 fork 中打一个语义化 tag（如
v0.4.1-myfix），不要用 commit hash —— Go 默认只信任 tag - 用
go mod edit -replace github.com/original/repo=github.com/yourname/repo@v0.4.1-myfix - 运行
go mod tidy && go mod download验证是否能完成，再git add go.mod go.sum提交 - 关键细节：fork 后别忘了同步 LICENSE 和必要文档，否则可能违反原协议
真正卡住的从来不是网络，是模块图里某个“看不见”的引用指向了虚空。修 go.mod 比调代理更有效，而 fork + tag 是唯一能让失控依赖重新可控的方式。
