Go mod tidy 报错“unknown revision”或“no matching versions”
直接原因是 Go 尝试解析一个没有明确 go.mod 的子目录路径，但该路径在远程仓库中并不存在独立模块声明。Go 不会自动把 github.com/user/repo/subdir 当成模块——它只认根目录或显式打过 tag 的子模块路径。
常见错误现象：go mod tidy 卡住、报 unknown revision；go get github.com/user/repo/subdir 失败；或者拉下来的是旧 commit，不是你期望的最新代码。
- 确认目标子目录下是否有
go.mod文件：没有就无法被 Go 视为独立模块 - 如果只是想引用代码（非发布模块），用
replace本地映射更可靠：replace github.com/user/repo/subdir => ./local/subdir
- 若必须走远程，且原仓库不支持子模块，只能 fork 后在子目录里补
go.mod并打 tag（如v0.1.0-subdir） - 别依赖未声明的子目录路径——Go 的模块系统不保证这种用法的稳定性
伪版本号（pseudo-version）是怎么生成的，为什么不能手动写
伪版本号形如 v0.0.0-20230412151822-1a2b3c4d5e6f，是 Go 根据 commit 时间戳和 commit hash 自动生成的，不是随意拼出来的字符串。
它用于标识一个没有打正式 tag 的 commit，让 go mod 能确定唯一性、支持可重现构建。手动改写会导致校验失败或模块下载异常。
立即学习“go语言免费学习笔记（深入）”；
- 伪版本号中的时间戳是 UTC，格式固定为
YYYYMMDDHHMMSS，不是本地时间 - commit hash 必须是完整 12 位以上，且属于该模块路径对应 repo 的有效 commit
- 如果写错 hash 或时间，
go mod download会静默失败，或后续go build报checksum mismatch - 查看当前使用的伪版本：运行
go list -m -v github.com/user/repo/subdir
想引用子目录但原项目没打 tag，又不想 fork，怎么办
最轻量的做法是用 commit hash 直接指定，Go 会自动转成伪版本号，且无需改动原仓库。
关键点在于：必须用完整模块路径（含子目录），且确保该路径在远程存在对应代码（即使没 go.mod），Go 才会尝试拉取。
- 执行
go get github.com/user/repo/subdir@1a2b3c4d5e6f（hash 至少 12 位） - Go 会自动解析出伪版本，并写入
go.mod，例如：github.com/user/repo/subdir v0.0.0-20230412151822-1a2b3c4d5e6f - 注意：如果子目录下无
go.mod，Go 会退回到整个 repo 的根go.mod去找依赖，可能引入意外的间接依赖 - 验证是否生效：
go list -f '{{.Dir}}' github.com/user/repo/subdir应返回本地缓存路径
为什么 go get -u 会把子目录引用升级成根模块
因为 -u 默认只看根路径的最新 tag，不感知子目录。当你写的是 github.com/user/repo/subdir，go get -u 实际去查 github.com/user/repo 的最新版本，然后把整个模块升级，再把子目录路径“降级”为根模块的一部分。
结果就是 go.mod 里子目录条目消失，变成根模块的一行，且版本可能跳变，导致编译失败。
- 永远不要对子目录路径用
go get -u - 升级子目录引用，只用
go get github.com/user/repo/subdir@commit或@vX.Y.Z（如果对方真打了子模块 tag） - 检查升级影响：
go mod graph | grep repo看依赖关系是否突变 - CI 中建议加
go mod verify，防止伪版本被意外覆盖
