go mod tidy 报 unknown revision 是因为本地被依赖模块未提交 git，go 要求 replace 指向的本地路径必须是含明确 commit 的 git 仓库；未提交或非 git 仓库均导致解析失败。
go mod tidy 报 unknown revision 是因为本地改动没提交
本地开发时改了被依赖的模块，但没 git commit，go mod tidy 就会卡在 unknown revision —— Go 要求所有 replace 指向的本地路径，其 Git 仓库必须有明确的 commit ID 才能解析版本。
常见现象：go mod tidy 报错类似 github.com/yourname/lib: unknown revision master 或 unknown revision v0.1.0，即使你已经在 go.mod 里写了 replace github.com/yourname/lib => ./local/lib。
- 先确认目标目录是 Git 仓库：
cd ./local/lib && git status，如果提示not a git repository，得先git init && git add . && git commit -m "init" - 如果有未提交修改，
go mod tidy默认忽略工作区脏状态，只认最近一次 commit；必须git add . && git commit -m "wip"才能生成可用 revision - 想跳过 commit 强制用当前代码？不行。Go 不支持 dirty tree 的 replace；临时方案是用
go mod edit -replace=github.com/yourname/lib=./local/lib后手动go mod vendor，但 CI 会失败
replace 指向本地路径后，CI 构建失败怎么办
replace 是开发期便利手段，但它不进 go.sum，也不上传，CI 环境里没有 ./local/lib 这个路径，自然找不到包。
正确做法不是“让 CI 也拉本地路径”，而是提前把改动发布出去：
- 本地模块改完 →
git push到远程仓库（哪怕私有）→ 在主项目里改go.mod的require行，比如github.com/yourname/lib v0.1.1-0.20260805123456-abcdef123456 - 或者打一个 tag：
cd ./local/lib && git tag v0.1.1 && git push --tags，再回主项目执行go get github.com/yourname/lib@v0.1.1 - CI 前加检查：
go list -m all | grep yourname/lib，确保输出的是远程 commit hash，不是=> ./local/lib
为什么 go get @commit 不生效，还是拉旧版
你以为 go get github.com/yourname/lib@abc123 就能锁定到那个 commit，但实际可能还是用了缓存里的旧版，尤其当 go.mod 里已有更高版本的 require 条目时。
根本原因：Go 的 MVS（最小版本选择）机制优先满足所有依赖的版本约束，@commit 只是 hint，不是强制指令。
- 先删掉已有 require：
go mod edit -droprequire=github.com/yourname/lib - 再精确拉取：
go get github.com/yourname/lib@abc123（注意 commit ID 必须存在且可访问） - 验证是否生效：
go list -m github.com/yourname/lib输出应含abc123，而不是v0.1.0或latest - 如果仍不对，
go clean -modcache清掉本地模块缓存，再重试
go.sum 里出现两个相同模块的不同 hash 怎么办
同一模块不同 commit 出现在 go.sum 里，说明项目里存在多个路径引用它——比如直接 require 了一次，又通过 replace 指向本地路径一次，Go 会为两者分别记录 hash。
这不是错误，但会导致构建行为不一致：本地用 replace 版本，CI 用 require 版本。
- 运行
go mod graph | grep yourname/lib查谁引入了哪个版本 - 删掉冗余的
replace，或统一用require+ 远程 tag - 执行
go mod tidy，它会自动清理未使用的 sum 条目 - 别手动删
go.sum行——删完再tidy可能拉到不同 commit，尤其当原 tag 被 force-push 覆盖时
