打标签是建立可追溯、可复现、可协作的版本控制机制，需串联代码提交、构建动作与运行环境；优先采用语义化版本（如v1.2.0），配合Git提交哈希（如build-abc123）确保溯源；按环境分标签（prod/staging等），禁用模糊标签和覆盖已发布标签。
打标签不是给镜像“起个名字”那么简单，而是建立可追溯、可复现、可协作的版本控制机制。核心在于：用标签把代码提交、构建动作和运行环境三者串起来，而不是只图方便写个 latest。
语义化版本优先，明确表达变更意图
对外发布或长期维护的镜像，必须使用 vX.Y.Z 格式，比如 v1.2.0、v2.0.0。这个数字不是随便编的，要和代码仓库的发布节奏一致：
- v1.2.0 表示主版本 1，新增了向后兼容的功能
- v1.2.1 表示修复 bug，不引入新功能也不破坏兼容性
- v2.0.0 表示有不兼容变更，需要同步更新文档和升级说明
避免加前缀如 release-v1.2.0，除非整个 CI/CD 流水线能自动识别并解析它。
用 Git 提交哈希确保构建可追溯
语义化版本管的是“发布”，而提交哈希管的是“构建源头”。在 CI 脚本里加入这行：
COMMIT_HASH=$(git rev-parse --short HEAD)
然后构建时打上这个标签：
docker build -t myapp:${COMMIT_HASH} .- 再配合语义版本一起推：
docker build -t myapp:v1.2.0 -t myapp:build-abc123 .
这样出问题时，直接查 abc123 就能定位到对应代码、CI 日志和构建产物，不用猜“这个 latest 到底是哪次提交编的”。
按环境和用途分标签，别混用
同一个镜像可以有多个标签，但每个标签要有明确归属：
-
myapp:v1.2.0→ 生产部署锁定版本 -
myapp:prod→ 指向当前生产用的稳定版（由脚本自动更新） -
myapp:staging-rc2→ 预发环境候选版本 -
myapp:main-20260708→ main 分支每日构建快照，仅保留 7 天
禁止单独用 dev、test 这类模糊词作标签，它们无法回溯来源，也容易被误用于生产。
严禁覆盖已发布标签，尊重镜像不可变性
标签只是指向镜像 ID 的指针，镜像本身不可变。但 Docker Registry 默认允许覆盖同名标签——这是危险操作：
- 已推送的
v1.2.0发现严重缺陷？→ 推送v1.2.1，而不是重推v1.2.0 - CI 脚本里应先尝试
docker pull myapp:v1.2.0，失败才构建推送，防止意外覆盖 - 旧版本归档建议保留最近 3 个主版本的全部次版本，更早的移入
archive/命名空间
不复杂但容易忽略。
