Go module 版本号带 pseudo-version 时怎么读提交时间

看到类似 v1.4.0-0.20260908112233-a1b2c3d4e5f6 的 Go module 版本号，先记住一个结论：中间的 14 位 yyyymmddhhmmss 是该修订的 UTC commit time，不是提交者填写的 author time。换算成本地时间后，才能和代码仓库的提交记录对上。

一、先按连字符拆出 pseudo-version 的三段

以 v1.4.0-0.20260908112233-a1b2c3d4e5f6 为例，不要把最后两段当成一个普通字符串。它可以这样读：

基准版本不是“这次提交所在分支的名字”。如果此前有 v1.4.0 标签，常见形式会把下一补丁版本写成 v1.4.1-0；如果没有可用标签，则可能从 v0.0.0 开始。它的任务是让伪版本既高于基准，又低于后续正式标签。

二、时间戳要看 commit time，不要直接看 author time

Git 一个提交可能同时有 author time 和 commit time：前者描述作者创作这份改动的时间，后者描述提交进入当前历史节点的时间。Go 伪版本使用后者。两者一致时不容易察觉，变基、转提交或跨时区协作后就可能相差很大。

换算时先把 14 位数字当作 UTC，再转换到本地时区。例如 20260908112233 表示 UTC 的 2026 年 9 月 8 日 11:22:33；在东八区应显示为 19:22:33。只把数字按本地时间解析，会得到相差八小时的错误结论。

版本中的时间只能帮助你定位大致修订，不能单独证明某一行代码是谁写的。最终还要用后面的模块元数据或仓库提交记录核对哈希。

三、用 go list -m -json 核对模块版本

依赖已经进入当前模块图时，可以查询模块的结构化信息。把模块路径替换成实际依赖，不要把示例路径原样复制到项目里：

# 查询当前模块图中的版本与 VCS 来源
go list -m -json example.com/widget

重点看三个字段：Version 是 Go 最终采用的规范版本；Time 是模块版本关联的时间信息；Origin 中若有修订来源，可继续对照 commit hash。查询结果为空或报模块不存在时，先确认模块是否在当前 build list，以及执行命令的目录是否属于正确的主模块。

package main

import (
	"fmt"
	"time"
)

func main() {
	// 伪版本中的时间必须按 UTC 读取，展示时再转换到本地时区。
	stamp := "20260908112233"
	t, err := time.Parse("20060102150405", stamp)
	if err != nil {
		// 输入长度或数字不合法时，不继续把它当成有效提交时间。
		panic(err)
	}
	fmt.Println("UTC:", t.Format(time.RFC3339))
	fmt.Println("Local:", t.Local().Format(time.RFC3339))
}

四、基准版本决定排序，异常时别手写伪版本

伪版本有三种常见外形：无已知基准时是 vX.0.0-时间-哈希；基准是预发布版本时，常见形式是 vX.Y.Z-pre.0-时间-哈希；基准是正式版本时，常见形式是 vX.Y.(Z+1)-0-时间-哈希。这里的 X 还必须和模块路径的主版本后缀保持一致。

如果只是想依赖某个分支或提交，优先让 go get 或 go list -m 根据分支名、提交哈希自动解析。Go 会检查基准标签是否是该修订的祖先、时间戳是否匹配修订、修订是否位于模块仓库的分支或标签历史中。手动把时间改成“看起来更新”的版本号，不能绕过这些约束。

常见问题

pseudo-version 中的时间是本地时间吗？

不是。它按 UTC 编码。展示给读者或排查日志时，先按 UTC 解析，再明确转换到目标时区。

为什么版本时间和 Git 日志时间不一致？

通常是把 author time 当成了 commit time，或把 UTC 数字直接按本地时区读取。两种时间字段和时区都要分别确认。

最后 12 位是完整提交哈希吗？

不是，它通常只是提交哈希的 12 位前缀。要做唯一核对，结合模块来源和仓库完整哈希。

能不能自己拼一个 pseudo-version？

不建议。让 Go 工具根据提交或分支生成规范版本，避免基准标签、时间和祖先关系不匹配。