Git 标签无法验签

核对 pnpm 的历史发布标签时，git verify-tag v11.18.0 报 cannot verify a non-tag object。这条错误应先按 Git 对象类型排查：版本名存在，不代表它指向一个带签名的 tag 对象。

在已核对的发布引用中，v11.18.0 直接指向 commit。它是轻量标签，verify-tag 没有可读取的 tag 签名。这个条件不能扩展成“pnpm 的所有标签都未签名”：较新的 v12.11.2 引用指向 tag 对象，但对象类型正确，也还不等于签名可信。

先区分缺少 tag 对象与签名校验失败

在已经取得相应引用的本地仓库中，可以查看对象类型。下面保留具体历史版本，检查其他版本时换成实际标签名：

git cat-file -t refs/tags/v11.18.0

输出 commit 时，引用直接指向提交；输出 tag 时，才有单独的附注标签对象。如果提示对象不存在，先核对仓库、引用名称和本地取得的版本，不能把“本地没有这个引用”判断成发布方没有签名。

轻量标签只是给对象起一个名称。附注标签则有独立的 tag 对象，可包含标签信息与签名。git verify-tag 验证的是后者的签名；没有 tag 对象时，反复调整 GPG 密钥、重装 Git，都不会凭空补出一份签名。

对象确实是 tag 后，再使用原来的验签命令：

git verify-tag v11.18.0

示例展示两项检查的区别，并不承诺这个历史标签会通过第二项。若换成一个已有 tag 对象的实际版本，仍需核对签名结果、签名者身份与项目既有信任规则。附注标签也可以不带签名。

提交的签名不能替代发布标签的签名

git verify-commit 检查提交签名。某个提交有可信签名，可以证明那份提交对象的签署情况；它并不能自动证明“这个提交被发布者指定为 v11.18.0”。版本名与提交之间的绑定，是标签验证要确认的另一件事。

如果发布流程要求签名标签，应取得发布方提供的真实签名标签对象，并按原有可信密钥或签名策略验证。旧版本没有相应对象时，保留这项证据缺口，按团队既定的制品验证规则决定是否接受，不能把提交验签成功改写成标签验签成功。

不要在本地用自己的密钥重新创建同名标签，再把 verify-tag 通过当成发布方证明。那只验证了自己刚创建的对象。也不要覆盖或强推远端标签，改变别人已经使用的发布引用。

验收要同时保留版本名、对象和信任判断

核对目标引用是否仍指向预期对象，标签签名是否满足实际发布要求，以及取得的制品是否属于这个版本。验签工具退出为零只是其中一项，不应省略签名者身份与既有信任策略。

如果错误已经变成缺失密钥、不受信任的签名者或签名损坏，就进入那个明确的验证分支；此时不再是 non-tag object。反过来，对象仍是 commit，就应继续处理缺少签名标签的事实，不通过关闭检查把它伪装成已验证的发布。