确认上游模块作者删除了 git 仓库中已发布的版本标签（如 v1.2.0），导致 go get 或 go mod tidy 无报错却未下载依赖，表现为 go.list -m all 不显示该模块且 curl 或浏览器访问对应 tag 返回 404。
go get 或 go mod tidy 无报错但没下载依赖，实际是模块作者删了 tag
这种情况不是你网络或配置的问题，而是上游模块作者手动删除了 Git 仓库中已发布的版本标签（比如 v1.2.0），导致 Go 模块系统在解析 require github.com/user/lib v1.2.0 时找不到对应 commit， silently 跳过——不报错、不下载、也不提示，go.mod 里那行还在，但 go list -m all 里压根不出现它。
怎么确认是不是 tag 被删了
别急着清缓存或换代理，先验证问题根源：
- 用
curl -I https://api.github.com/repos/user/lib/git/ref/tags/v1.2.0（替换为你的模块路径和版本）看返回是否是404 Not Found - 或者直接浏览器打开
https://github.com/user/lib/releases/tag/v1.2.0，页面 404 就坐实了 - 运行
go list -m -json github.com/user/lib@v1.2.0，如果输出为空或报unknown revision v1.2.0，就是 tag 消失了
三种可行的应对方式，按推荐顺序
修复目标是让依赖能解析、能构建、且不破坏语义版本契约：
-
优先尝试升级到现存 tag：查该模块最新可用 tag（
git ls-remote --tags https://github.com/user/lib | grep -E '\.0$' | tail -5），然后go get github.com/user/lib@v1.2.1（假设 v1.2.1 存在且兼容） -
临时 replace 到 commit hash：如果作者只删了 tag 但没删 commit，用
git log --oneline找到对应版本的 hash（比如abc1234），再执行go mod edit -replace github.com/user/lib=github.com/user/lib@abc1234 -
降级到更早稳定 tag：若 v1.2.0 是破坏性变更点，而 v1.1.0 还在，就
go get github.com/user/lib@v1.1.0，再手动检查 API 差异
replace 后必须清理并验证
replace 不是万能胶，容易埋雷：
- 执行
go mod tidy后，go.sum里会多出一行校验和，但它是针对 commit 的，不是 tag —— 后续别人拉代码时若没同步 replace 规则，会直接失败 - 务必把
replace行写进go.mod，不能只靠命令临时生效；否则 CI/他人构建时照样崩 - 上线前用
go mod verify确认所有依赖校验通过，再跑一遍go build -o /dev/null ./...看是否真能编译
最麻烦的不是 tag 消失本身，而是它让依赖链变成“看似正常、实则断裂”的静默状态。一旦发现某依赖在 go list -m all 输出里缺席，又排除了 GOPROXY/GOPRIVATE 问题，基本就是这个原因。
