当go mod找不到合法语义化版本tag时生成伪版本，格式为vX.Y.Z-yyyymmddhhmmss-abcdefabcdef，其中vX.Y.Z为基准版本，时间戳为UTC提交时间，abcdefabcdef为commit hash前12位。
伪版本号什么时候被生成
当 go mod 找不到合法的语义化版本 tag 时，就会 fallback 到伪版本（pseudo-version）。这不是你操作失误，而是 Go 工具链在“尽力而为”：它试图从 Git 提交历史中提取一个可排序、可追溯的版本标识。
常见触发场景包括：
- 远程仓库压根没打任何
vX.Y.Z格式的 tag - 打了 tag，但格式非法，比如
1.2.3（缺v）、v1.2.3-rc1（应为v1.2.3-rc.1）、v1.2.3+2023（+构建元数据被 Go 完全忽略） - 你显式运行了
go get example.com/lib@commit-hash或@main - 依赖模块本身没有
go.mod文件（此时还会附带+incompatible标记）
伪版本号的标准格式长什么样
Go 生成的伪版本号不是随机字符串，而是有严格结构的时间+哈希组合，用于保证可比较性和唯一性。它的通用形式是：
vX.Y.Z-yyyymmddhhmmss-abcdefabcdef
其中：
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
vX.Y.Z是“基准版本”：如果仓库最近一个合法 tag 是v1.5.0，那伪版本就以v1.5.0开头；如果没有合法 tag，则用v0.0.0 -
yyyymmddhhmmss是 UTC 时间戳（注意：不是本地时间），对应该 commit 的提交时间，用于版本排序 -
abcdefabcdef是该 commit 的 Git hash 前 12 位（小写），确保能准确定位代码
例如：v1.0.10-0.20220805095508-6c1f3628ef7a 表示基于 v1.0.10 后的某次提交，时间是 2022-08-05 09:55:08 UTC，commit hash 前 12 位是 6c1f3628ef7a。
为什么 go list -m -versions 看不到你的 tag
go list -m -versions 只列出 Git 仓库中**符合 SemVer 正则 ^v\d+\.\d+\.\d+(-[0-9A-Za-z.-]+)?$ 的 tag**，其他一概无视。它不看分支、不看 commit、不看轻量 tag（lightweight tag）是否公开。
如果你的 tag 显示不出来，大概率是以下之一：
- tag 名是
release/v1.2.3或1.2.3—— 必须是纯v1.2.3 - tag 是
v1.2.3-beta1—— 应写成v1.2.3-beta.1（点分隔） - 你在 GitHub/GitLab 上打了 tag，但没 push 到远程：
git push origin v1.2.3缺失 - tag 是 annotated tag 但未签名，或被设为 private（某些私有 Git 服务会隐藏）
伪版本带来的实际风险
伪版本本身不是 bug，但它是“临时方案”的信号。长期依赖伪版本会埋下几个隐性坑：
- commit 被 force-push 覆盖或分支被删后，
go mod download会失败，报invalid version—— 因为那个 hash 找不到了 - 不同开发者本地
go mod tidy可能拉到不同 commit（如果都基于@main），破坏构建一致性 - CI/CD 流水线里若缓存了旧伪版本，升级时可能卡住，因为
go get -u不会自动跳到新伪版本（它只认合法 tag） - 审计和合规场景下，伪版本无法对应到正式发布记录，难以追溯
最稳妥的做法：对所有对外提供依赖的模块，坚持打合法 vX.Y.Z tag，并确保 go list -m -versions 能列出来。伪版本只应在开发调试阶段短期使用，上线前必须替换为真实语义化版本。
