自定义 docker 镜像版本管理应遵循语义化版本（semver）规范，强制使用 vx.y.z 格式，与 git tag 严格对齐；禁用 latest，生产环境必须使用固定版本标签；支持组合标签（如 v1.3.0-prod）补充上下文；全部打标与推送须通过 ci 自动化完成，杜绝手动操作。
对自定义 Docker 镜像做版本号规范化管理，核心是把“打标签”变成有规则、可预期、可追溯的动作，而不是随意用 latest 或临时哈希应付。关键不在技术难度，而在建立团队共识和自动化约束。
坚持语义化版本（SemVer）为主干
所有对外发布或需长期维护的镜像，必须使用 vX.Y.Z 格式，例如 v1.3.0、v2.0.0-rc2：
- MAJOR（主版本）：发生不兼容变更时递增，比如重构数据库迁移逻辑、删除旧 API 接口
- MINOR（次版本）：新增向后兼容功能，如加了健康检查端点、支持新配置项
- PATCH（修订版）：仅修复 bug 或安全补丁，不改行为、不加功能
版本号必须与代码仓库的 Git tag 严格对齐。CI 流水线检测到 git tag v1.3.0 才触发构建，避免人工输错。
禁用 latest，用明确标签锁定生产环境
latest 不是版本，是漂移指针——今天推的是 v1.3.0，明天覆盖成 v1.4.0，线上就可能意外升级。
- 生产部署清单（如 Helm values 或 K8s YAML）里，镜像字段必须写死具体版本，如
myapp:v1.3.0-prod - 若需“最新稳定版”别名，可额外打一个
stable标签，但只允许通过审批流程或自动化脚本显式更新，禁止自动覆盖 - CI 脚本中加入校验：推送前先
docker pull registry/myapp:v1.3.0，失败才构建推送，防止误覆盖
组合标签补充上下文，不破坏 SemVer 主干
单一语义版本不够表达全部信息？那就叠加短横分隔的修饰符，保持机器可解析、人可读：
-
v1.3.0-prod：已通过生产验证的同一镜像 -
v1.3.0-git-7f3a1b2：绑定源码提交，确保镜像与代码完全一致 -
v1.3.0-amd64或v1.3.0-arm64：标明 CPU 架构，多平台构建时必备 -
v1.3.0-debug：仅用于排障，含符号表但不含敏感配置
避免堆砌过长标签（如 v1.3.0-prod-arm64-debug-glibc），复杂变体建议用 manifest list 管理。
自动化打标与推送，杜绝手动操作
每次构建都靠人手敲 docker tag 容易漏、易错、难审计。应在 CI 中固化流程：
- 从 Git 获取版本：
git describe --tags --abbrev=0提取最近 tag；或用git tag -l 'v*' | sort -V | tail -n1 - 生成带偏移的开发标签：
git describe --tags输出类似v1.3.0-2-g7f3a1b2，适合非发布分支 - 构建完成后，自动执行多标签打标：
docker tag $IMG_ID myorg/myapp:$SEMVER myorg/myapp:$GIT_HASH myorg/myapp:prod-$SEMVER - 逐个推送（Docker 不支持批量 push）：
for t in $TAGS; do docker push myorg/myapp:$t; done
镜像仓库中可通过前缀快速筛选，比如查所有生产镜像：v1.3.*-prod，或所有某次提交产物：*-git-7f3a1b2。
