go mod tidy 超时本质是网络链路或代理问题，非模块本身故障；需正确配置 goproxy（如国内用 https://goproxy.cn,direct）、gonoproxy（私有域名），子模块需手动初始化且路径匹配；内网可选 vendor、私有代理或本地缓存方案；go get -u 应慎用，推荐 go get -u=patch 或指定模块更新，并及时执行 go mod tidy 同步 go.sum。
go mod tidy 超时卡在 downloading 阶段
本质是网络链路不稳定或代理响应慢，不是模块本身有问题。常见现象是命令卡住十几分钟，最后报 Get "https://proxy.golang.org/…": context deadline exceeded 或直接退出无提示。
优先检查是否已设 GOPROXY：运行 go env GOPROXY，确认输出不是 https://proxy.golang.org 或空值。国内必须设为 https://goproxy.cn,direct（注意末尾 direct 不可省）。
- 临时生效：
go env -w GOPROXY="https://goproxy.cn,direct" - 若用 VSCode，还需在设置里加
"go.toolsEnvVars": {"GOPROXY": "https://goproxy.cn,direct"}，否则gopls仍走默认代理 - 私有域名（如
git.corp.company）必须加进GONOPROXY，否则会被代理转发导致 404：go env -w GONOPROXY="git.corp.company"
克隆含大量子模块的仓库时 go mod tidy 失败
不是 go mod 的问题，而是子模块本身没初始化或版本不匹配。Go 不会自动递归拉取 Git 子模块，go mod tidy 只管 Go 模块依赖，不管 Git 子模块状态。
典型错误：执行 go mod tidy 报 module github.com/xxx/yyy@v1.2.3: reading github.com/xxx/yyy/go.mod at revision v1.2.3: unknown revision v1.2.3 —— 实际是子模块未检出对应 commit。
- 先手动初始化子模块：
git submodule update --init --recursive - 确认子模块目录下存在
go.mod文件，且路径与主项目go.mod中声明的 module 名一致（例如子模块仓库地址是https://git.example.com/lib/utils，则其go.mod第一行必须是module git.example.com/lib/utils） - 若子模块用的是 SSH 地址（
git@git.example.com:lib/utils.git），需确保~/.gitconfig有[url "git@git.example.com:"] insteadOf = https://git.example.com/，否则go get仍尝试走 HTTPS 协议失败
内网环境没有公网代理时的替代方案
不能连外网 ≠ 不能用 Go Module。核心是把依赖“带进来”，而不是“实时拉”。三种可行路径，按推荐顺序排列：
- 用
go mod vendor：在能联网的机器上执行该命令，生成vendor/目录，再把整个项目（含vendor/）拷进内网。注意：go build -mod=vendor才会真正用 vendor，否则仍尝试远程拉取 - 搭私有代理（如
goproxy或athens）：部署在内网服务器，配置GOPROXY=http://10.0.1.5:8080。首次拉取后所有后续请求走缓存，速度极快 - 禁用校验 + 本地缓存：设
go env -w GOSUMDB=off和GOPROXY=direct，然后把所需模块的.zip包（从 goproxy.cn 下载）解压到$GOMODCACHE对应路径，go mod tidy就能识别
go get -u 导致间接依赖爆炸式增长
克隆大仓库后执行 go get -u，常引发几十个间接依赖被升级，其中某些模块更新后引入新依赖或破坏兼容性，反而让 go mod tidy 更容易超时或失败。
真正需要的只是同步补丁级更新，而非全量升级。Go 1.19+ 支持精准控制：
-
go get -u=patch：只升补丁版（v1.2.3 → v1.2.5），跳过v1.3.0 -
go get -u=minor：升次要版（默认行为，慎用） - 指定单个模块更新：
go get github.com/sirupsen/logrus@v1.9.3，避免波及无关依赖
最容易被忽略的是：go get 命令修改 go.mod 后，必须立刻跑一次 go mod tidy，否则 go.sum 不同步，下次构建可能因校验失败中断。
