容器镜像的版本管理通常没有源代码版本那么受重视，但镜像标签一旦缺少规则，发布链路就会变得非常脆弱。很多团队在构建时直接使用 docker build 而不显式指定标签，Docker 就会自动给镜像打上 latest。这个 latest 并不代表最新稳定版，更不代表任何兼容性承诺，它只是一个默认别名。要让镜像在开发、测试、预发布和生产环境之间安全流转，必须设计一套清晰的版本与标签策略，把构建来源、发布语义和运行时锁定方式都考虑进去。
一套好的标签策略不是单纯给镜像编个号，而是要让每一次构建都能被追溯到代码提交、流水线编号和依赖状态。接下来从 latest 的陷阱、语义化版本映射、可变标签与不可变标签的取舍，以及 CI/CD 自动化四个层面展开。
一、为什么不能把 latest 当作发布标签
latest 是 Docker 在构建或推送时未指定标签的情况下给出的默认标签。使用 docker build -t app . 会产生 app:latest，使用 docker pull nginx 时也默认可拉取 nginx:latest。这种便利性在本地开发中没问题，但一旦进入共享环境，latest 就变成了一个浮动指针。
例如，上午推送了包含新功能的 nginx:latest，下午又因为紧急修复重新推送了一次。此时任何拉取 latest 的服务都无法确定自己拿到的是哪个版本，回滚操作也很难明确回到之前的正确状态。更重要的是，Docker 不会校验 latest 是否兼容旧配置，也不会阻止覆盖。生产环境一旦依赖 latest，就等于放弃了版本锁定的能力。
因此，发布流程中必须显式给镜像打上可识别的版本标签，并约定 latest 只能作为开发或演示用途，不应出现在生产部署清单中。这个约束需要写进团队的发布规范，而不是依靠口头约定。
二、用语义化版本建立标签映射
语义化版本（SemVer）是镜像标签设计中最常用的基础。它将版本号划分为 major.minor.patch，分别表示主版本、次版本和补丁版本。例如 1.4.2 中，1 是主版本，4 是次版本，2 是补丁版本。主版本变化通常意味着不兼容的 API 改动，次版本变化可能是向后兼容的新功能，补丁版本则是缺陷修复。
在镜像标签策略中，建议每次发布补丁或次版本时，至少同时生成完整版本号标签和次版本标签。例如发布 v1.4.2 时，可以给镜像打上 1.4.2、1.4 和 1 三个标签。这样下游服务可以选择固定到 1.4.2 获得完全不可变版本，也可以选择 1.4 获得该次版本系列中的补丁更新，或者选择 1 获得主版本级别的兼容更新。具体采用哪种粒度，取决于服务的风险偏好。
下面的命令展示了如何一次构建并打多个标签：
docker build \ -t registry.ipipp.com/app:1.4.2 \ -t registry.ipipp.com/app:1.4 \ -t registry.ipipp.com/app:1 \ .
如果版本由 Git 标签触发，可以在流水线中解析标签并自动生成多个镜像标签：
VERSION=${CI_COMMIT_TAG#v}
docker build -t registry.ipipp.com/app:${VERSION} .
docker push registry.ipipp.com/app:${VERSION}
MINOR=${VERSION%.*}
docker tag registry.ipipp.com/app:${VERSION} registry.ipipp.com/app:${MINOR}
docker push registry.ipipp.com/app:${MINOR}
MAJOR=${MINOR%.*}
docker tag registry.ipipp.com/app:${VERSION} registry.ipipp.com/app:${MAJOR}
docker push registry.ipipp.com/app:${MAJOR}
这种映射策略让镜像版本与代码版本保持同步，也有利于在发布说明和监控系统中快速定位问题。
三、区分可变标签、不可变标签与摘要引用
镜像标签可以粗略分为两类：可变标签和不可变标签。latest、stable、dev 这类名称通常属于可变标签，因为团队可能随时把新的镜像推送到同一个标签。版本号或 Git 提交哈希则更接近不可变标签，因为它们与一次具体构建绑定，正常流程下不会重复推送。
可变标签并非完全没有价值。在开发环境中，开发人员频繁构建并覆盖 dev 标签可以减少配置修改，提升迭代速度。但当镜像流转到测试、预发布或生产环境时，必须切换到不可变标签或直接使用镜像摘要（digest）。摘要由镜像内容和元数据计算得出，例如 sha256:开头的字符串。即使标签被覆盖，摘要仍然指向同一个镜像内容。
可以通过以下命令查看镜像摘要：
docker pull registry.ipipp.com/app:1.4.2
docker inspect --format='{{index .RepoDigests 0}}' registry.ipipp.com/app:1.4.2
生产编排系统最好使用摘要而不是标签，例如 Kubernetes 中可以使用 registry.ipipp.com/app@sha256:xxxx 的引用方式。这样即使有人误推送了相同标签，运行中的 pod 也不会意外漂移。摘要引用是镜像版本锁定中最严格的一种形式。
四、在 CI/CD 流程中自动生成标签
手工打标签容易遗漏或写错，因此标签策略需要固化到 CI/CD 流水线中。常见的做法是：开发分支构建出带有提交哈希的镜像，发布标签构建出带有语义化版本的镜像，主干合并可选打上 latest 或其他可变标签。
以 GitLab CI 为例，可以用下面的配置构建基于提交哈希的镜像：
build:
stage: build
script:
- docker build -t registry.ipipp.com/app:${CI_COMMIT_SHA} .
- docker push registry.ipipp.com/app:${CI_COMMIT_SHA}
当开发者推送一个形如 v1.4.2 的 Git 标签时，流水线再解析语义化版本并生成对应标签。发布标签的处理可以单独放在一个 job 中：
if [[ "${CI_COMMIT_TAG}" =~ ^v[0-9]+\.[0-9]+\.[0-9]+$ ]]; then
VERSION=${CI_COMMIT_TAG#v}
docker build -t registry.ipipp.com/app:${VERSION} .
docker push registry.ipipp.com/app:${VERSION}
fi
同时要避免在发布流程中盲目推送 latest。如果团队确实需要 latest，建议只在主分支稳定构建通过后自动更新，并明确标识该标签仅供集成环境使用。
此外，镜像仓库通常会保留大量过期标签，建议设置清理策略。可以按时间删除超过 90 天的开发分支镜像，保留主版本和最近几个补丁版本的标签，避免仓库膨胀和运维混乱。
五、落地过程中的常见错误与约束
镜像标签策略失败的原因通常不是缺少规则，而是规则没有和实际部署链路打通。例如构建系统里正确打上了 1.4.2，但部署清单却写死了 latest，这样策略就形同虚设。因此制定策略后，要检查所有部署文件、Helm values、环境变量和运维脚本，确认生产环境没有引用浮动标签。
另一个常见错误是频繁覆盖同一版本标签。即使标签看起来像版本号，只要它被重新推送，就不具备不可变性。团队应该约定：同一个语义化版本标签一旦推送到公共仓库，就不得再次覆盖。如果发现缺陷，应该发布新的补丁版本，而不是修改旧的镜像。
最后，建议把镜像摘要记录到发布单或部署回执中。这样在问题排查时，可以直接比对生产拉取的 digest 与构建产物是否一致。结合镜像签名工具（如 Cosign）对镜像进行签名验证，可以进一步防止供应链攻击和中间人篡改。好的版本与标签策略最终要服务于可追溯、可回滚和可验证这三个目标。