go mod tidy 无输出是因模块缓存与 go.mod 声明映射断层，常见于项目重命名、路径变动或 module 行修改；需验证 go list -m all、检查 module 路径一致性、避免 gopath/src、用 go clean -modcache 清理缓存，并确认 goprivate 和 goproxy 配置正确。
go mod tidy 无输出也不下载依赖，先看缓存是否卡住
这不是命令坏了，而是模块缓存和当前 go.mod 声明之间出现了映射断层。最典型的情况是项目重命名、移动目录或手动改过 module 行后，go mod tidy 仍试图复用旧缓存路径，结果静默失败——不报错、不下载、也不提示。
验证方式很简单：
- 运行
go list -m all，如果输出为空或只显示标准库，基本就是缓存没对上 - 检查
go.mod里的module声明（比如module github.com/you/new-project）是否与当前项目物理路径一致 - 确认没把项目放在
$GOPATH/src下——Go 模块模式下放这里会触发兼容逻辑，导致识别异常
清理模块缓存必须用 go clean -modcache，别删 pkg/mod 手动目录
go clean -modcache 不只是删除文件，它还会重置 Go 工具链内部的缓存索引状态。手动删 $GOMODCACHE 目录下的内容，容易残留元数据或权限问题，反而让后续 go mod tidy 更难重建一致性。
执行前注意：
- 该命令会清空所有模块缓存，包括其他项目的依赖，不是仅限当前项目
- 清理后首次
go mod tidy会较慢，因为要重新下载全部依赖 - 如果项目依赖私有仓库，确保
GOPRIVATE已设好，否则清理后照样拉不到
私有仓库报 403 或 “no protocol found”，重点查 GOPRIVATE 和 GOPROXY 配置冲突
错误信息像 gitlab.company.com/group/project@v1.2.1: no protocol found for repository 或 403 Forbidden，本质是 Go 尝试用公共代理去访问本该直连的私有地址。
关键检查点：
- 运行
go env GOPRIVATE，确认输出包含你的私有域名（如gitlab.company.com），支持通配符但**不能带协议头或路径** - 运行
go env GOPROXY，确保值里有direct作为 fallback（例如https://goproxy.cn,direct） - 如果用了
replace指向本地路径，注意路径必须是绝对路径或以./开头，相对路径会被忽略
go mod tidy 卡在某个模块不动，加 -v 参数定位阻塞点
没有超时提示不等于没在干活。有时它卡在某个间接依赖的版本解析上，比如某私有模块的 go.mod 文件本身不可达，或 Git 服务器响应极慢。
用这个命令暴露真实行为：
go mod tidy -v
输出里每行都会标出正在 fetch 的 URL 和状态码。常见线索：
- 停在
https://proxy.golang.org/.../list→ 公共代理不可达，需切GOPROXY - 停在
https://gitlab.company.com/.../go.mod→ 私有域名没进GOPRIVATE，或凭据失效 - 反复重试同一 URL 后 timeout → 网络或 Git 服务问题，可临时设
GOPROXY=direct测试
真正麻烦的不是命令不工作，而是它不说话——没报错、没进度、也没日志。你得主动用 -v、go list -m all 和 go env 把它的沉默拆开看。缓存、代理、私有域这三处，漏掉任何一个，go mod tidy 都可能变成一个安静的摆设。
