镜像生命周期管理需用结构化语义化标签明确环境、版本、时间与构建标识，禁用latest，按项目配置差异化保留策略，并通过删除标签+垃圾回收两步清理存储，标签生成须嵌入CI/CD流水线。
靠标签管好镜像生命周期，核心是让每个标签自带“身份”和“时效”——不是随便起个名字就完事，而是用结构化命名明确它属于哪个环境、什么版本、何时构建、是否稳定。这样后续清理、回滚、部署才能自动识别、精准执行。
用语义化标签定义版本与用途
标签不是别名，而是关键元数据。推荐统一格式：应用名:主版本.次版本.修订号-环境-构建标识，例如 payment-service:2.1.0-prod-20260421-abc789。
- v1.2.0、v2.1.0 这类语义化版本用于生产发布，支持按版本号排序、灰度切流、一键回滚
- -dev、-test、-rc 后缀明确隔离环境，避免测试镜像误推到生产仓库
- 附加 git commit ID（如 abc789）或时间戳（如 20260421），确保每次构建可追溯、不可覆盖
- 完全弃用
latest标签——它不指向固定内容，会破坏部署一致性与审计要求
按项目/环境配置差异化保留策略
不同环境对镜像的留存需求差异很大，不能一刀切。在 Harbor、Nexus Pro 或阿里云 ACR 等支持策略的仓库中，为每个项目单独设置规则：
-
prod 项目：保留匹配
^v[0-9]+\.[0-9]+\.[0-9]+$的正式版本，且至少留 10 个；排除beta、rc类标签 - test/dev 项目：只保留最近 7 天推送的镜像，或最多保留 5 个最新 tag，加快空间回收
-
base/common 项目：按基础镜像类型（如
python-slim、node-alpine）分组，保留每个主版本的最新小版本（如 v3.11、v3.12）及 LTS 版本
清理前先解引用，再回收存储
删除 tag 不等于释放磁盘——它只是断开引用，底层 layer 仍存在。必须两步走：
- 第一步：调用仓库 API 或界面执行 tag 删除（Harbor 可在保留策略中启用 “删除未匹配的 tag”）
- 第二步：触发垃圾回收（GC），Harbor 中叫 “Garbage Collection”，Registry 中运行
garbage-collect命令，Nexus Pro 自动联动 - 务必开启
--dry-run预览，确认将删哪些 manifest 和 blob，避免误清被其他 tag 共享的 layer
把标签逻辑嵌入 CI/CD 流水线
标签生成不能靠人工，必须由流水线自动完成：
- Git Tag 推送时，CI 触发构建并打
vX.Y.Z标签，推送到 prod 仓库 - 合并到 main 分支时，打
main-{short-commit}并推 test 仓库 - PR 构建时，打
pr-{pr-number}-{short-commit}，仅存于 dev 项目，过期自动清理 - 所有构建镜像同时写入 LABEL 元数据（如
maintainer=devops@company.com、build-date=2026-04-21T10:11:00Z），供后续扫描与审计使用
