docker镜像标签是部署链路的语义锚点，须用同一镜像id、多标签区分环境与版本；推荐vx.y.z-env格式，禁用latest，结合仓库路径隔离环境并配rbac权限。
企业级多环境发布中，docker镜像标签不是简单后缀，而是部署链路的语义锚点。关键在于用同一镜像id支撑dev/staging/prod全流程，靠标签区分用途而非重建镜像。
按环境+版本双维度打标
每个镜像应至少拥有两个标签：一个指向语义化版本（如v2.3.1），另一个标明目标环境（如prod）。这样既能通过版本号回溯变更，又可按环境快速筛选部署目标。
- 生产环境统一用 vX.Y.Z-prod 格式，例如
v2.3.1-prod - 预发环境用 vX.Y.Z-staging，与生产镜像完全一致，仅标签不同
- 开发环境可用分支名或时间戳，如
dev-feature-login-20261009，避免污染主干标签空间
CI/CD流水线自动注入元数据
构建阶段就应将Git提交哈希、构建时间、CI流水线编号等信息固化进标签，确保任意镜像都可精准定位来源。
- 推荐组合格式：v2.3.1-git8a7f2b-ci1042（版本+哈希+构建号）
- 在Jenkins/GitLab CI中通过环境变量动态生成：
docker tag myapp:${VERSION} myapp:${VERSION}-git${GIT_COMMIT:0:7}-ci${CI_BUILD_ID} - 该标签用于内部追踪，不直接用于部署，但能极大提升故障排查效率
禁止在生产中使用 latest 标签
latest 不是“最新版”，而是“最后被打上的那个标签”。它会被反复覆盖，导致相同配置在不同时间拉取到不同镜像，破坏部署一致性。
- 生产K8s Deployment中必须显式指定带版本号的标签，如
image: registry.example.com/app:v2.3.1-prod - 若需保留“当前稳定版”概念，可用
stable标签替代，并由人工或审批流程更新，而非自动覆盖 - 私有仓库中可配置策略，禁止向
latest推送生产镜像
镜像仓库命名空间隔离环境
光靠标签还不够，建议结合仓库路径做物理隔离，降低误操作风险。
- 开发镜像推送到
registry.example.com/dev/myapp:v2.3.1 - 生产镜像推送到
registry.example.com/prod/myapp:v2.3.1-prod - 配合RBAC权限控制，使开发人员无法推送或拉取
/prod/下的镜像
