用语义化版本+环境后缀（如v1.2.0-rc1、v1.2.0-staging、v1.2.0-prod）区分镜像，绑定Git哈希确保可追溯，禁用latest但可人工维护stable标签，并按环境差异配置Harbor保留策略。
用标签把测试、预发、生产环境的镜像明确区分开，是保障版本可控的核心手段。关键不是打多少标签，而是每个标签有确定含义、不可覆盖、可追溯。
语义化版本 + 环境后缀
避免只用 v1.2.0 这类孤立标签，而应组合环境与阶段信息：
- v1.2.0-rc1：候选发布版，用于内部验收和自动化冒烟测试
- v1.2.0-staging：已通过验收，部署到类生产环境做端到端验证
- v1.2.0-prod：经 staging 验证无误后，正式打标并推送到生产仓库
- 所有环境标签都指向同一个镜像 digest，确保内容完全一致，仅语义不同
Git 提交哈希作为唯一锚点
每次构建都应绑定代码源头，防止“同标签不同代码”问题：
- CI 脚本中自动提取
git rev-parse --short HEAD，生成如 sha-abc123 标签 - 该标签与语义化标签共存：
docker tag myapp:v1.2.0-prod myapp:sha-abc123 - 故障时可快速反查对应代码分支、CI 构建日志和测试报告
禁止 latest，但可保留 stable
latest 是漂移源，必须禁用；但可设计受控的别名机制：
- 不许在任何 CI/CD 流水线中 push
latest，也不许在 k8s Deployment 中引用它 - 允许人工维护一个 stable 标签，仅由发布负责人在 prod 版本验证通过后手动打标
- 搭配 Harbor 保留策略，设置
exclude tags matching "stable|v[0-9]+.[0-9]+.[0-9]+-prod"，防止误删
清理要分环境、有节奏
不同环境的镜像生命周期差异大，不能一刀切：
- dev/test：按数量保留最近 20 个，或按时间保留 7 天，高频迭代不需留痕
- staging：保留每轮完整发布链（如 v1.2.0-rc1 → v1.2.0-staging → v1.2.0-prod）
- prod：至少保留最近 3 个正式版本（v1.1.0-prod、v1.2.0-prod、v1.2.1-prod），满足回滚需求
- Harbor 中配置定时保留策略，并开启 dry-run 模式先验证再执行
