go mod tidy 无输出但依赖未下载，大概率是分支重命名后模块缓存未清理；需运行 go clean -modcache 清空缓存，再执行 go mod tidy 重新解析依赖，并检查 replace 语句是否使用 commit hash 或本地路径而非分支名。
go mod tidy 无输出但依赖没下载，大概率是分支重命名后缓存没清
项目从 main 分支切到 master（或反过来），或者把远程仓库默认分支名改了，go mod tidy 就可能静默失败——不报错、不下载、也不提示。这不是网络或权限问题，而是 Go 模块缓存里还存着旧分支的解析记录，新 go.mod 里的 replace 或间接依赖路径无法匹配缓存条目。
- 先确认是否真卡在缓存：运行
go list -m all，看输出里有没有缺失的依赖项，或出现(incompatible)却没版本号 - 检查
go.mod中所有replace行，确保指向的本地路径或新分支 URL 是可访问的（比如github.com/user/repo => ./local-fork要存在且含有效go.mod） - 别只删
go.sum或vendor/——这些不影响模块索引，必须清缓存本身
清理模块缓存的正确命令不是 rm -rf，而是 go clean -modcache
go clean -modcache 是 Go 官方提供的安全清理方式，它会清空 $GOMODCACHE 目录（可通过 go env GOMODCACHE 查看路径），同时保留 Go 工具链对缓存结构的控制权。直接 rm -rf $GOPATH/pkg/mod 可能导致后续 go mod download 失败，尤其在启用了 GOPROXY 的环境下。
- 执行前确保当前目录是项目根目录（含
go.mod） - 运行
go clean -modcache后，立即跟go mod tidy——这次它会重新拉取所有依赖，包括按新分支名解析的版本 - 如果用的是私有 Git 仓库，确认
GONOPROXY已包含对应域名，否则仍会走 proxy 并 404
分支重命名后 replace 语句容易漏掉版本号或 commit hash
当把 replace github.com/org/repo => github.com/org/repo v1.2.3 改成指向新分支时，很多人只改 URL，忘了 v1.2.3 是旧分支上的 tag。新分支若没打同名 tag，Go 就无法解析，go mod tidy 会跳过这条 replace 并继续用老缓存。
- 替换为具体 commit：改成
replace github.com/org/repo => github.com/org/repo e8a3f2c（e8a3f2c 是新分支 HEAD 的 short hash） - 或改用本地路径：
replace github.com/org/repo => ../repo-fork，前提是../repo-fork/go.mod的module声明与原路径一致 - 避免写
@main或@master——Go 不支持分支名作为版本标识，只认 tag、commit、pseudo-version
go get 拉不到新分支上的依赖？检查 GOPROXY 和模块路径一致性
执行 go get github.com/org/repo@main 报 no matching versions，常见原因是 GOPROXY（如 https://proxy.golang.org）缓存了旧分支的元数据，而新分支尚未被 proxy 索引。
- 临时禁用 proxy 测试：
GOPROXY=direct go get github.com/org/repo@e8a3f2c - 确认远程仓库的
go.mod第一行module声明没变——分支重命名不等于模块重命名，模块路径仍是github.com/org/repo - 如果模块路径确实变了（比如从
github.com/org/repo改成gitlab.example.com/group/repo），必须同步更新所有import语句，不能只改go.mod
go.mod、replace、import、proxy 缓存，四者必须严格对齐。少对一环，go mod tidy 就会沉默。
