规范化镜像版本管理需用docker tag为同一镜像id绑定多个语义化标签，如v1.5.2、v1.5.2-prod、20260619等，禁用latest，严格对齐git tag，推送时逐个显式执行。
用 docker tag 规范化管理镜像版本，核心是把“同一个镜像 ID”绑定多个有含义的标签，而不是靠改名或重建。关键不在命令多复杂，而在标签怎么起、什么时候打、推不推得准。
标签命名必须带语义，别碰 latest
标签不是随便写的备注，它得让人一眼看懂用途和来源。生产环境严禁只用 latest，因为它会漂移，下次拉取可能就不是你测试过的那个镜像。
- 主版本优先用语义化格式：
v1.5.2、v2.0.0-rc1，和代码仓库的 Git tag 严格对齐 - 补充信息用短横连接：
v1.5.2-amd64（架构）、v1.5.2-alpine（基础镜像）、v1.5.2-prod（部署环境） - 避免模糊词：
test、new、final单独作 tag 没意义，无法追溯也无法自动化
一次构建，多个标签，靠 docker tag 补全
构建命令（docker build）通常只打一个初始 tag，比如 myapp:dev。真正规范化的操作是在构建完成后，用 docker tag 补上其他正式标签。
- 先确认镜像 ID 或已有标签：
docker images | grep myapp - 假设刚构建出的镜像是
myapp:dev，ID 是a1b2c3d4，可立刻补标：docker tag a1b2c3d4 myorg/myapp:v1.5.2docker tag a1b2c3d4 myorg/myapp:v1.5.2-proddocker tag a1b2c3d4 myorg/myapp:20260619 - 所有标签指向同一 ID，不占额外空间，但为不同场景提供了明确入口
推送要逐个显式执行，不能省
Docker 不支持 docker push myapp:v1.5.2 v1.5.2-prod 这种写法。每个 tag 都得单独 push，否则远程仓库里只有部分标签存在。
- 安全做法是写成脚本或 CI 步骤：
docker push myorg/myapp:v1.5.2docker push myorg/myapp:v1.5.2-proddocker push myorg/myapp:20260619 - 推送前建议先
docker pull校验目标 tag 是否已存在——防止误覆盖已发布的版本 - 私有仓库若开启不可覆盖策略，这步校验能提前失败，避免流程中断
团队协作必须统一命名层级
单人玩得转，多人协作时命名混乱就会互相踩坑。推荐固定结构：[环境]-[版本]-[构建标识]，例如：
-
prod-v1.5.2-6a8f1b3：生产环境，v1.5.2 版本，Git 提交前 7 位 -
staging-v1.5.2-20260619：预发环境，同版本，按日期标记 - 仓库名一律小写+短横：
user-service，不用下划线或大写；命名空间体现归属：finance/user-service
