go mod download卡住的直接原因是Go默认失败即中止，不重试不跳过；需用-v/-x定位断点，清理损坏缓存或临时设GOPROXY=direct重试单模块，离线环境须预热缓存并设GOPROXY=off和GOSUMDB=off。
go mod download 卡住或断流的直接原因
不是网络波动本身，而是 Go 默认行为：遇到单个模块下载失败（如超时、校验失败、重定向异常），go mod download 会立即中止，不继续尝试其他模块。它不重试、不跳过、不并发回退——这是设计使然，不是 bug。
用 -x 和 -v 参数看清断在哪一步
盲目重试没用，先定位真实断点。加 -v 能看到每个模块的拉取 URL 和状态码；加 -x 还能打印出实际执行的 curl 或 git 命令：
go mod download -v -x
常见线索包括：
-
Get "https://proxy.golang.org/...": dial tcp: i/o timeout→ 代理不可达 -
verifying github.com/xxx@v1.2.3: checksum mismatch→GOSUMDB没关或缓存污染 -
403 Forbidden→GOPRIVATE没覆盖私有域名，被转发到公共代理 -
zip: not a valid zip file→ 对应模块缓存损坏，路径在$GOMODCACHE/github.com/xxx/@v/v1.2.3.zip
强制续传：删坏包 + 用 direct 模式重试
Go 不支持“断点续传”，但可以精准清理后重试：
- 查出报错模块名（比如
github.com/some/badpkg） - 删掉它的缓存：
rm -rf $(go env GOMODCACHE)/github.com/some/badpkg - 临时绕过代理重拉：
GOPROXY=direct go mod download github.com/some/badpkg@v1.2.3 - 再跑完整命令：
go mod download
注意：GOPROXY=direct 仅本次生效，不影响全局配置；它让 Go 直连源站（GitHub/GitLab 等），适合调试单个失败模块。
离线环境必须提前预热缓存
局域网或无网机器上，go mod download 本质是读盘，不是下载。所谓“断流”其实是缓存不全：
- 在有网机器上，先确保
go mod tidy成功，再执行go mod download - 确认缓存完整：
go list -m all | xargs -I{} go list -m -f '{{.Dir}}' {} | head -n 3查几个路径是否存在 - 打包整个
$(go env GOMODCACHE)目录（不是软链接！），解压到离线机相同路径 - 离线机必须设
GOPROXY=off和GOSUMDB=off，缺一不可
漏掉任一模块，或路径不一致，go mod download 就会卡住——它不会提示“缺哪个”，只会静默等待。
