规范化镜像生命周期管理需闭环管控“建、存、用、清”四环节，依托标准化命名（registry/project/app-name）、场景化标签策略、构建时嵌入LABEL元数据、策略化清理（含Dry Run与GC）、权限与流程强绑定（如Harbor项目隔离+CI卡点）。
规范化管理应用镜像生命周期，核心是把“建、存、用、清”四个环节串成一条可追溯、可控制、可审计的闭环。不是靠人工盯，而是靠规则驱动、工具支撑、标准统一。
命名与标签必须标准化
混乱的镜像名和随意打的标签（比如latest、dev、test123）是后续所有问题的源头。
- 统一使用三段式命名：
registry/project/app-name，例如harbor.example.com/prod/payment-service - 标签策略按场景区分：生产环境用语义化版本（
v1.4.2），测试环境可用 Git Commit ID（abc1234）或短日期（20260812），严禁在生产镜像上覆盖latest - 关键镜像额外打保护标签，如
prod-stable或certified-2026Q3，便于策略识别和保留
元数据要嵌入构建过程
光有名字和标签不够，镜像得“自带身份证”。这些信息不靠人记，而靠 LABEL 指令在构建时写死。
- 至少包含：
maintainer=team-ops@company.com、source=https://git.example.com/app/payment、base-image=ubuntu:22.04、build-date=2026-08-13T11:52:00Z - CI 流水线中自动注入 Git 分支、提交哈希、构建流水号等，让每个镜像可精准回溯到代码和构建上下文
- Harbor 等 Registry 支持基于 LABEL 查询，为自动化治理提供依据
清理必须策略化、可预演、定时执行
镜像不会自己消失，靠“想起来删”等于没管。要用保留策略（Retention Policy）代替人工判断。
- 在 Harbor 中为不同项目配置差异化策略：dev 项目保留最近 15 个镜像或 7 天内推送的；prod 项目保留带
v[0-9]+.[0-9]+.[0-9]+标签的全部版本 + 最近 6 个月内的所有rc-镜像 - 务必启用 试运行（Dry Run） 功能，确认将删哪些镜像后再真正执行
- 保留策略只移除 Tag 引用，需配套定期触发 垃圾回收（GC） 才能释放磁盘空间——建议每周日凌晨自动运行一次
权限与流程要绑定环境层级
谁能在哪个环境推/拉/删镜像，不能靠口头约定，而要通过 Registry 的项目级权限和 CI/CD 流水线卡点来 enforce。
- Harbor 中划分
dev、test、staging、prod等独立项目，设置不同角色（developer 只能 push dev/test，ops 才能 push prod） - CI 流水线中增加强制检查：push 到 prod 项目前，必须通过镜像扫描（CVE 无 critical）、签名验证、且标签匹配正则
^v[0-9]+\.[0-9]+\.[0-9]+$ - 禁止直接
docker push到生产仓库，所有镜像必须经由 CI 构建并附带完整元数据后才允许入库
