3. 镜像版本管理：标签规范、语义化版本与仓库清理

镜像版本管理这事儿，说简单也简单，说复杂能让你头大。我见过太多团队，一开始随便打个 latest 标签就上线了，结果三个月后，谁都不知道线上跑的是哪个版本。嗯，今天咱们就把这块彻底聊透。

3.1 镜像标签规范——别让名字变成灾难

先说说标签。我个人习惯，标签就是镜像的身份证。你想想看，如果身份证上只写了个「张三」，那跟没写有啥区别？

我建议的标签格式是这样的：

<项目名>-<主版本>.<次版本>.<修订号>-<构建号>

举个例子：

user-service-2.1.3-b20240315
payment-api-1.0.0-b20240314
gateway-3.2.1-b20240313

为什么要这么搞？我在项目中遇到过，有次线上出了 bug，运维小哥对着十几个 latest 标签的镜像，完全不知道哪个才是生产环境在用的。最后只能一个个拉下来跑一遍，折腾了整整半天。

这里有几个避坑指南：

• 别用 latest 作为生产标签——它应该只用于开发环境
• 别用时间戳作为唯一标识——同一时间可能构建多个版本
• 别用中文或特殊字符——有些工具对 Unicode 支持不好

3.2 版本号语义化——让版本说话

语义化版本，说白了就是让版本号自己告诉你：这次更新有多大动静。

标准格式是：

主版本号.次版本号.修订号

规则其实很简单：

版本位	什么时候加	举个例子
主版本	不兼容的 API 修改	2.0.0 → 3.0.0
次版本	向下兼容的功能新增	2.1.0 → 2.2.0
修订号	向下兼容的问题修复	2.1.3 → 2.1.4

我曾经接手过一个项目，版本号从 1.0.0 直接跳到 2.0.0，结果只是改了个日志格式。你想想看，这要是让下游团队看到了，不得吓一跳？他们以为 API 全变了，实际上啥都没动。

还有一个细节：预发布版本怎么处理？我习惯用这样的格式：

1.0.0-alpha.1
1.0.0-beta.2
1.0.0-rc.3

alpha 是内部测试，beta 是公开测试，rc 是发布候选。这样团队里每个人都能清楚知道，这个镜像处于什么阶段。

3.3 镜像仓库的清理策略——别让仓库变成垃圾场

镜像仓库这东西，你不清理，它就会慢慢膨胀。我记得有次帮客户做审计，发现他们的 Harbor 仓库里躺着 3000 多个镜像，其中 80% 都是三个月前的旧版本。磁盘空间直接爆了。

清理策略，我总结了三板斧：

1. 按时间清理——保留最近 N 天的镜像
2. 按版本清理——只保留每个主版本的最近几个次版本
3. 按标签清理——删除所有 latest 和 dev 标签的旧镜像

具体怎么配？拿 Harbor 举例：

# 清理策略示例
- 保留最近 30 天的镜像
- 每个仓库最多保留 10 个标签
- 删除所有未打标签的镜像
- 保留每个主版本的最后 3 个次版本

还有一个容易被忽略的点：镜像的层（layer）清理。你删除了一个镜像，但它的层可能还被其他镜像引用。所以清理的时候，要确保层也被真正释放了。

我建议用这样的流程：

1. 标记过期镜像
2. 等待 7 天观察期
3. 确认没有回滚需求
4. 执行清理
5. 验证磁盘空间释放

这个观察期很重要。你想想看，万一刚删完就发现需要回滚，那不就傻眼了？

3.4 知识体系总览

下面这张图，把镜像版本管理的核心逻辑串起来了：

说白了，镜像版本管理就三个目标：可追溯、可回滚、可清理。标签规范保证你能找到它，语义化版本告诉你它是什么，清理策略确保仓库不会爆炸。

最后说一句：这些规范最好写进团队的 CI/CD 流程里，靠人肉执行迟早会出问题。自动化才是王道。