Docker镜像仓库管理多版本应用的核心是通过结构化标签（如应用名:主版本.次版本.修订号-环境-构建时间）统一标识版本与环境，禁止使用latest，同一构建结果用docker tag打多个标签并推送，私有仓库按项目隔离，部署时严格指定完整镜像路径。
用Docker镜像仓库管理多版本应用，核心是把“版本”和“环境”两个维度落到标签（tag）上，并通过统一仓库集中分发。不靠人工记忆，也不靠改配置文件切换，而是让镜像自己“带身份”上线。
明确标签命名规则，让每个镜像可读、可追溯
标签不是随意起的别名，而是结构化标识。推荐采用：应用名:主版本.次版本.修订号-环境-构建时间，例如：payment-service:2.4.1-prod-20260428 或 payment-service:2.4.1-staging-20260428-abc7f2e。
- 固定使用语义化版本号（如
v2.4.1），避免latest—— 它无法回滚、不可审计 - 环境后缀必须明确：用
prod、staging、dev，不用production这类长词，减少拼写错误 - 构建时间建议用
YYYYMMDD格式；若需区分同天多次构建，追加 Git 短哈希（如-abc7f2e） - 同一镜像可打多个标签，比如构建一次，同时标记为
v2.4.1、prod、20260428，但生产部署只认v2.4.1-prod
用一个构建动作生成多个标签，保证一致性
不同标签如果分别构建，哪怕代码完全一样，镜像ID也会不同——这会破坏可重现性。正确做法是在 docker build 后，用 docker tag 批量挂载标签。
- 先构建基础镜像：
docker build -t myapp:build . - 再一次性打多个标签：
docker tag myapp:build myrepo/myapp:v2.4.1-prod myrepo/myapp:v2.4.1-staging myrepo/myapp:20260428 - 最后统一推送：
docker push myrepo/myapp:v2.4.1-prod && docker push myrepo/myapp:v2.4.1-staging - CI/CD 中建议用 Makefile 或脚本封装，防止漏推某一个标签
私有仓库中按项目隔离，避免标签冲突
多个团队或服务共用一个仓库时，光靠标签不够，必须用命名空间（namespace）做物理隔离。例如 Harbor 中创建 finance 和 marketing 两个项目，各自维护自己的镜像路径：
harbor.example.com/finance/payment-service:v2.4.1-prodharbor.example.com/marketing/landing-page:v1.8.0-staging- 不同项目间权限独立，开发组无法误删生产镜像
- 配合 Harbor 的“保留策略”，可自动清理
dev标签下超过7天的旧镜像，而prod标签永久保留
拉取时严格指定完整路径+标签，杜绝隐式行为
部署脚本或 Kubernetes YAML 中，镜像地址必须写全，包括仓库域名、项目名、镜像名和标签：
- ✅ 正确：
image: harbor.example.com/finance/payment-service:v2.4.1-prod - ❌ 错误：
image: payment-service:latest（本地无该镜像则拉取失败；有则可能是过期版本） - 在 CI 流水线中，可用变量注入标签，如
image: harbor.example.com/app:${IMAGE_TAG}，但变量值必须由构建阶段生成并校验 - Kubernetes 配合 ImagePullPolicy: IfNotPresent 即可，无需 Always —— 只要标签不变，镜像就不会重复拉取
