核心是用语义化标签区分镜像环境，如v1.2.0-rc1、v1.2.0-staging、v1.2.0-prod，均指向同一digest；绑定git哈希（如sha-abc123）确保可追溯；禁用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 - 出问题时能快速反查对应分支、构建日志和测试报告
禁用 latest，但可人工维护 stable
latest 是漂移源，必须禁用：
- 不许在 CI/CD 流水线中 push
latest，也不许在 Kubernetes 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 模式先验证再执行。
