Go模块版本号必须以v开头并严格遵循语义化版本格式，如v1.2.3；否则go工具链拒收，fallback生成非法伪版本报invalid pseudo-version错误。
不是你装错了 Go，而是模块版本号格式不合法，Go 工具链直接拒收。
为什么出现 invalid pseudo-version 错误
这个错误不是来自 Go 二进制本身，而是 go mod 在解析依赖版本时发现某个 tag 或引用不符合语义化版本（SemVer）硬性规则，于是 fallback 到生成伪版本（pseudo-version），但该伪版本又因格式异常被判定为非法。
- 常见诱因是 Git tag 写成了
1.2.3、release/v1.2.3、v1.2.3-rc1（缺点分隔符）或v1.2.3+2023（含构建元数据） - Go 只认严格形如
v1.2.3、v0.1.0、v2.0.0-beta.1的 tag；+xxx部分会被完全忽略，-rc1会报错，必须写成-rc.1 - 如果远程仓库打了非法 tag，而你的
go.mod里又写了require example.com/lib v1.2.3（没加v），go mod tidy就会试图构造伪版本并失败
go get 和 go list -m -versions 对版本号的校验逻辑
这两条命令背后共享同一套解析器：先查远程 tag 列表，再逐个匹配正则 ^v\d+\.\d+\.\d+(-[0-9A-Za-z.-]+)?$。不匹配的 tag 直接被跳过，不会出现在 go list -m -versions 输出中，go get 也就找不到目标版本。
-
go list -m -versions github.com/your/repo输出为空？大概率是远程没打合法vX.Y.Ztag，或者只打了轻量 tag（git tag v1.2.3），没打注解 tag（git tag -a v1.2.3 -m "..."） -
go get github.com/your/repo@v1.2.3报invalid pseudo-version？先运行git ls-remote --tags origin | grep v1.2.3确认 tag 是否存在且命名正确 - 私有仓库（GitLab/GitHub Enterprise）还要检查 tag 是否 public —— 某些配置下 lightweight tag 不对外暴露
修复步骤：从本地到远程全链路检查
别急着删 go.sum 或重装 Go，按顺序排查：
立即学习“go语言免费学习笔记（深入）”；
- 执行
go version确认是go1.25.0（当前唯一受支持版本），避免旧版工具链解析差异 - 检查项目
go.mod中所有require行：每个版本字符串是否都以v开头？例如require github.com/some/lib v1.5.0✅，require github.com/some/lib 1.5.0❌ - 对每个出问题的依赖，去其 GitHub/GitLab 页面翻 tag 列表，确认是否存在对应
vX.Y.Ztag；若只有1.2.3，需联系作者修正或临时用@commit-hash替代 - 你自己发版时，务必用
git tag -a v1.2.3 -m "release"+git push origin v1.2.3（不是--tags）
容易被忽略的细节：预发布版与主版本路径耦合
写 v1.2.3-alpha.1 没问题，但一旦你打 v2.0.0，就必须同步改两处：模块路径和 import 路径。否则 go mod tidy 会尝试把 v2.0.0 解析成伪版本，然后报 invalid pseudo-version。
-
go.mod第一行必须是module github.com/you/lib/v2（不是/v1也不是无后缀） - 所有调用方代码必须改成
import "github.com/you/lib/v2"，漏掉/v2就算 tag 合法也会触发伪版本 fallback -
go list -m all输出里若看到incompatible字样，说明某依赖的 v2 版本被当作了不兼容分支，根源几乎一定是路径没改对
真正卡住人的从来不是 Go 版本高低，而是那一行少写的 v、那个没推的注解 tag、或者 import 路径里漏掉的 /v2——这些地方一错，工具链就放弃语义解析，转头造伪版本，然后立刻判死刑。
