先记住这个答案
发版 tag 强烈建议选附注标签。轻量标签仅存提交哈希，无作者、日期与说明，无法证明谁在何时发布；附注标签则创建独立对象，携带打标签者信息与消息，并支持 GPG 签名。发布行为需要可追溯、可校验，故生产发版强烈建议使用附注标签，临时标记可用轻量。
- 发版 tag 强烈建议使用附注标签
- 轻量标签缺少 tagger 与时间戳
- 附注标签可被 GPG 签名与核验
存储模型与可审计元数据的差异
轻量标签只是在 refs/tags/ 下写入一个指向提交的 40 位哈希，类似不会移动的分支。git show v1.0-lw 直接显示被指向提交的内容，无任何额外记录。附注标签则通过 git tag -a 创建一个 tag 对象，其中包含 tagger 的姓名、邮箱、打标签日期、消息以及指向提交的引用。运行时 git show v1.0 会先展示 tag 对象自身的信息，再显示提交。
发版审计要求能回答"这个版本是谁在什么时间发布的"。轻量标签只记录提交哈希，多人使用同一提交时无法区分打包者；附注标签把 tagger 身份固化，并且该对象有独立的 SHA-1，可被 GPG 签名。若后续需要核验发布者公钥，唯有附注标签具备签名空间。这是二者在 Git 对象模型层面最根本的机制差异。
前端版本事故：只有一个轻量标签
某前端仓库发布 v2.3.0 时，维护者图省事执行 git tag v2.3.0（轻量），推送后没有记录发布说明。第二天发现该版本存在严重样式回归，需要紧急热修。团队回看 commit 历史发现提交高度一致，但 git show v2.3.0 只显示提交与作者时间，没有任何关于"这次发布做了什么变更、谁批准"的信息。QA 要求追溯发布负责人与变更清单时，只能翻阅聊天记录，效率低下且无法自动审计。
假如当初使用 git tag -a v2.3.0 -m "release 2.3.0"，git show 就会列出 tagger 的邮箱与打标签时间，配合 GPG 签名还能确认是 CI 密钥还是个人密钥。热修时基于该 tag 创建分支，也能依据 tag 对象中的说明快速识别基线内容。这一场景说明：审计追溯不是事后补救，而是打 tag 那一瞬间标签类型决定的。
哪些场景轻量标签可接受
轻量标签并非绝对禁止，但只适用于临时指针或内部实验。例如在本地仅想快速标记某个提交来运行性能对比，或给 CI 构建队列添加一个不会长期存在的标记，此时无需 tagger 信息。但一旦该标记需要推送到共享远程供团队或工具消费，就应升级为附注。不同 Git 托管平台在 UI 创建标签时的默认类型可能不同，使用前可用 git cat-file -t 确认类型。
发版标签若使用轻量，签名校验将无法实现——git tag -v 会直接报错，因为轻量标签没有可验证的对象。此外，轻量标签被误删后无法恢复 tagger 信息。若强行用 git tag -f 移动轻量标签，历史记录中不会留下修正痕迹。因此建议：凡是会交付给外部或留作版本基线的 tag，优先走附注流程，并可搭配 git push --follow-tags 只推送附注标签。
容易答错的地方
- 轻量标签更省空间所以用轻量
- 附注标签多一个对象，但其体积只有几百字节，相对代码仓库可忽略。发版审计的价值远超这点存储成本，节省空间不是理由。
- tag 只是静态指针，两种没区别
- 轻量指针无法记录发布人、时间与说明，也不能签名。在需要合规追责或自动发布流程里这是本质差别。使用
git show可直观看到差异。
面试官还会怎么问？
如何检查远程 tag 是轻量还是附注？
用 git cat-file -t <tag>：输出 tag 则是附注（对象类型），输出 commit 则是轻量。也可用 git for-each-ref --format='%(objecttype)' refs/tags/ 查看各 tag 的对象类型。
附注标签可以签名吗？
可以，使用 git tag -s 调用 GPG 私钥签名，之后用 git tag -v <tag> 验证。签名保证 tag 对象与 tagger 身份未被篡改，但不会覆盖提交历史本身的完整性。
误用了轻量标签还能补成附注吗？
可以：删除原轻量标签 git tag -d <tag>，再基于相同提交创建附注，然后使用 git push --force --tags 强制更新远程。若已有他人引用则需协调，且历史上会短暂出现缺失。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。