答案：Go报“unknown revision”或“module not found”主因是模块tag被删除或force push覆盖，需先确认tag是否存在，再用replace指向含日期前缀的pseudo-version（如v1.2.3-0.20230515123456-abcdef123456）并执行go mod tidy更新go.sum。
go mod download 报 “unknown revision” 或 “module not found”
这不是网络问题，也不是代理配置错误，而是模块仓库里某个 v1.2.3 这样的 tag 被人工删除或 force push 覆盖掉了。Go 默认只认 git commit 的 tag，不认分支名或 commit hash（除非显式指定），一旦 tag 消失，go mod download 就会卡在解析阶段，报错类似：unknown revision v1.2.3 或 module github.com/user/repo: reading https://proxy.golang.org/github.com/user/repo/@v/v1.2.3.info: 404 Not Found。
- 先确认是否真被删：用浏览器或
curl -I https://proxy.golang.org/github.com/user/repo/@v/v1.2.3.info查看返回是否为 404；也可直接去对应 GitHub/GitLab 仓库的 Releases 页面确认 tag 是否还在 - 如果 tag 确实没了，但你又必须用这个“逻辑版本”，有两种现实路径：
- 让上游重新打 tag（最规范，但常不可控）
- 在本地
go.mod中用replace指向一个可用 commit（临时救急）：replace github.com/user/repo => github.com/user/repo v1.2.3-0.20230515123456-abcdef123456
—— 注意后半段是commit hash，不是分支名；Go 支持这种 pseudo-version 格式，前提是该 commit 存在且能被 git 解析
- 别用
replace github.com/user/repo => ./local-copy指向本地目录来绕过——这会让 CI/CD 构建失败，因为其他机器没有这个路径
go.sum 校验失败伴随 “invalid version”
当 tag 被删后，即使你用 replace 强行指向某个 commit，go mod tidy 仍可能报 verifying github.com/user/repo@v1.2.3: checksum mismatch。这是因为 go.sum 里存的是原 tag 对应的 zip 文件哈希，而你现在拉的是 commit 的 zip，内容不同。
- 执行
go mod download github.com/user/repo@v1.2.3-0.20230515123456-abcdef123456后，再跑go mod tidy，它会自动更新go.sum为新 commit 的校验值 - 如果旧
go.sum条目残留导致冲突，可手动删掉对应行（以github.com/user/repo v1.2.3开头的两行），再重新go mod tidy - 切勿直接
go env -w GOSUMDB=off—— 这会跳过所有校验，仅限本地调试，CI 环境绝对不能开
私有模块 tag 删除后，GOPRIVATE 不起作用？
GOPRIVATE 只控制“是否走代理”，不解决“tag 不存在”的根本问题。即使你设了 go env -w GOPRIVATE="git.company.com"，只要 git.company.com/team/repo 仓库里 v2.1.0 tag 被删，go mod download 依然失败。
- 验证私有库可达性：在终端运行
git ls-remote git@git.company.com:team/repo.git refs/tags/v2.1.0，看是否返回空 —— 空即表示 tag 真没了 - 若用 HTTPS 访问私有库，确保 Git 凭据已缓存（
git config --global credential.helper store），否则go会静默失败 - 紧急时可在
go.mod中写死 commit：replace git.company.com/team/repo => git.company.com/team/repo v2.1.0-0.20240101000000-1234567890ab
，注意格式必须含-0.YYYYMMDDHHMMSS-前缀，否则 Go 不识别为 pseudo-version
CI 构建因 tag 缺失中断，怎么快速恢复？
GitHub Actions / GitLab CI 里跑 go mod download 失败，往往不是配置问题，而是上游变更未同步到你的认知中。关键在于“不依赖别人打的 tag”，尤其对非公开维护的模块。
- 把关键依赖的 commit hash 锁进
go.mod的replace，比锁 tag 更可靠 —— tag 可删，commit 不可删（除非仓库被重置） - CI 脚本开头加检查：
go list -m all | grep 'github.com/user/repo' || echo "WARNING: dependency missing" && exit 1，提前暴露问题 - 长期方案：推动团队建立 tag 管理规范，禁止删除已发布的 semver tag；或改用 commit hash + date 作为 pseudo-version 发布（如
v1.2.3-20260805-abcdef）
