镜像版本管理应采用语义化版本（vX.Y.Z）为主，辅以架构、发行版等上下文标识；开发阶段可用分支+提交哈希命名；严禁覆盖已发布tag，须通过新版本号修复问题。
镜像版本管理的核心是让 tag 既能表达语义，又可被自动化识别和追溯。不建议只用 latest，也不推荐纯时间戳或随机哈希——关键在于建立可读、可查、可依赖的命名逻辑。
语义化版本优先（SemVer 风格）
对对外发布、需长期维护的镜像（如基础运行时、公共组件），采用 vX.Y.Z 格式打标，例如 v1.2.0、v1.2.1、v2.0.0。版本号含义需与代码仓库保持一致：
- v1.2.0 → 主版本 1，次版本 2，修订版 0；表示向后兼容的功能新增
- v2.0.0 → 主版本升级，可能含不兼容变更，应同步更新文档与升级指南
- 避免在 tag 中混用前缀（如
release-v1.2.0），除非团队明确约定前缀含义且 CI/CD 全链路支持解析
构建上下文标识补充（非替代 SemVer）
单一语义版本可能对应多次构建（如不同平台、不同配置）。可在主 tag 后追加短横分隔的上下文标识，保持可读性与机器可解析性：
-
v1.2.0-amd64、v1.2.0-arm64—— 明确 CPU 架构 -
v1.2.0-alpine、v1.2.0-ubuntu22.04—— 区分基础镜像发行版 -
v1.2.0-debug—— 仅用于调试环境，不含生产敏感信息但带完整符号表 - 避免过长组合，如
v1.2.0-alpine-arm64-debug-glibc，应通过多阶段构建或 manifest list 管理复杂变体
分支与环境关联 tag（开发协同场景）
对未发布到正式渠道的镜像（如功能验证、预发测试），可用分支名 + 提交简写方式辅助追踪：
-
feat/auth-abc123—— 分支名feat/auth下提交abc123构建的镜像 -
main-20240520—— main 分支每日构建，日期格式统一为YYYYMMDD - 这类 tag 不应被生产环境引用，CI 流水线可自动清理超过 7 天的此类 tag
- 禁止使用模糊词如
test、dev、new单独作 tag，无法定位来源
镜像不可变性与 tag 生命周期管理
tag 是指向镜像 ID 的指针，本身不携带内容。一次推送不应覆盖已有 tag（尤其语义版本），否则破坏可重现性：
- Docker Registry 默认允许覆盖同名 tag，需在 CI 脚本中显式校验：
docker pull $IMAGE:$TAG失败才构建推送 - 对已发布的
v1.2.0，若发现严重缺陷，应发布v1.2.1，而非重推v1.2.0 - 定期归档旧版本：保留最近 3 个主版本（v1.x、v2.x、v3.x）的全部次版本，更早版本移至
archive/命名空间或离线存储
