go mod download卡住是因为模块含大文件且未发布规范版本，导致go退回到git直连下载。可通过go mod download -x查看是否执行git clone，并用git sparse-checkout或replace本地精简版解决。
go mod download卡在某个模块不动，其实是它带了大文件
Go 模块本身不禁止打包二进制资源（比如测试用的视频、PDF、模型权重），但 go mod download 会把整个 Git 仓库（含历史提交）按 tag 或 commit hash 全量拉下来——哪怕你只 import 了其中一行代码。现象就是：卡在 github.com/xxx/large-assets 几分钟没反应，go mod download -x 日志里反复出现 git clone 或 git fetch，而不是走代理的 GET https://goproxy.cn/...。
- 这不是代理没配好，而是 Go 工具链主动退回到了 Git 协议直连（因为该模块未发布到 proxy.golang.org 或镜像站，或其
go.mod里声明了replace/require到一个无 tag 的 commit） - goproxy.cn 等镜像只缓存符合 Go Module 规范的发布版本（即有
go.mod+ 语义化版本 tag），对无 tag 的 commit 或含巨量 binary 的仓库基本不缓存 - Git 协议拉取受本地网络质量、SSH 配置、Git LFS 是否启用等影响极大，且无法被
GOPROXY加速
怎么判断是不是大资源问题
先确认是否真被大文件拖慢：
- 执行
go mod download -x <module>@<version></version></module>，看最后几行是git clone还是GET https://goproxy.cn/... - 手动
git clone --depth 1该仓库，观察是否卡住或下载速度极慢；再git ls-tree -r --name-only HEAD | grep -E "\.(bin|zip|tar|pdf|mp4)$"查是否有明显大文件 - 检查该模块的
go.mod是否用了replace指向本地路径或无 tag 的 commit ——这种写法会让 Go 绕过代理，强制走 Git
绕过 Git 直连，用 replace + 本地缓存替代
如果确认是大资源导致，不要硬等 go mod download，改用人工控制：
- 手动下载该模块的干净版（去掉大文件）：用
git clone --filter=blob:none（Git 2.22+）或git sparse-checkout只拉go.mod和源码目录 - 把精简后的代码放本地路径，例如
~/go-mods/github.com/xxx/large-assets - 在项目
go.mod中加：replace github.com/xxx/large-assets => ../go-mods/github.com/xxx/large-assets - 运行
go mod tidy，此时不再触发远程 Git 拉取，而是直接链接本地副本
注意：replace 不会上传到远程仓库，仅限本机开发；上线前需确认该模块是否有官方轻量 release 版本，或推动上游拆分资源。
GOSUMDB=off 不能解决大文件问题，但能避免校验卡死
大资源模块常伴随 checksum mismatch 或 sum.golang.org 超时，因为校验服务器无法处理超大 blob。这时临时关校验可让流程跑通，但不是提速根源：
-
GOSUMDB=off go mod download可跳过哈希校验，避免卡在verifying ...阶段 - 但它不影响 Git clone 本身的速度，该慢还是慢
- 仅用于调试，上线前必须恢复
GOSUMDB=on，否则失去依赖完整性保护 - 真正要解决“慢”，得从源头切断 Git 依赖——要么换轻量版模块，要么用
replace隔离
最容易被忽略的是：你以为配好了 GOPROXY 就万事大吉，结果模块本身就没走代理通道；而 go mod download -x 的日志里那一行 git clone 就是唯一真相。别猜，直接看它到底在干什么。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
