Docker镜像标签需采用语义化版本（如v1.2.0）为主干，关联Git哈希或时间戳确保可追溯，按环境分层打标（dev-/test-/vX.Y.Z-prod），禁用latest于生产部署。
规范化管理 docker 镜像标签的核心，是让每个标签都具备明确含义、可追溯、不可覆盖、环境可控。它不是给镜像随便起个名字，而是建立一套与代码版本、构建过程和部署阶段强关联的语义体系。
用语义化版本（SemVer）作为主干标签
主版本号.次版本号.修订号（如 v1.2.0）是最推荐的基础标签格式：
- 主版本号变动（v1→v2）表示不兼容变更，生产环境升级需严格评审
- 次版本号变动（v1.2→v1.3）代表新增功能且向后兼容，适合灰度发布
- 修订号变动（v1.2.0→v1.2.1）仅修复缺陷，可直接用于热更新
- 所有正式发布必须打此格式标签，禁止仅用
latest或v1这类模糊标识
绑定构建来源，确保可追溯
单靠版本号还不够——得知道这个 v1.2.0 对应哪次代码提交：
- 在 CI 流水线中自动注入 Git 短哈希，生成类似 v1.2.0-gitabc123 的复合标签
- 也可组合时间戳，如 v1.2.0-20261009，便于按日期筛选历史镜像
- 避免使用纯数字构建号（如 build-456），除非该编号已在 CI 系统中全局唯一且可反查提交
按环境分层打标，隔离风险
同一镜像可以同时拥有多个标签，但不同环境应有专属前缀或后缀：
-
开发环境：用
dev-abc123或feature/login-abc123，强调分支与提交 -
测试环境：用
test-v1.2.0或staging-gitabc123，由自动化流程打标并触发测试任务 -
生产环境：只允许
v1.2.0和v1.2.0-prod这类显式标识，且必须经人工审核或 GitOps PR 合并后才生效
禁用 latest，但可策略性复用
latest 不是不能用，而是不能“依赖”：
- 仅保留在本地开发或 CI 构建中间阶段，比如
docker build -t myapp:latest .作为临时别名 - 推送前必须重打为语义化标签，例如：
docker tag myapp:latest myapp:v1.2.0 && docker push myapp:v1.2.0 - 绝不允许 Kubernetes Deployment 或 Helm Chart 中写死
image: myapp:latest
