2. 核心概念：版本控制基础、镜像不可变性、校验和（Checksum）原理

好，咱们正式进入第二章节。在开始动手做回滚保护和镜像校验之前，有几个底层概念必须得先捋清楚。说白了，如果你不理解「版本」是怎么来的、「镜像」为什么不能改、「校验和」到底在算什么东西，那后面所有的自动化脚本和策略都是空中楼阁。

我见过太多团队，一上来就写 CI/CD 流水线，结果回滚时发现镜像标签被覆盖了，或者拉下来的包跟预期不一致。嗯，这些坑，其实都是基础概念没打牢。今天咱们就把这三块地基夯实。

2.1 版本控制基础：给每一份交付件贴上唯一标签

版本控制，不只是 Git 里那个 commit hash。在运维和交付的语境里，版本控制的核心目标是：让每一个制品（镜像、包、配置文件）都有一个全局唯一、可追溯的标识。

我个人习惯把版本号分成三段来看：

但光有语义化版本还不够。我在项目中遇到过一个问题：同一个 v2.5.3 的镜像，开发在本地打了一次，CI 又打了一次，结果两个镜像的 SHA256 不一样。为什么？因为构建环境的时间戳、依赖缓存不一样。

版本控制的本质，就是给「变化」一个坐标。没有坐标，回滚就是瞎蒙。

2.2 镜像不可变性：写一次，永远不变

镜像不可变性，是容器化交付的基石。你想想看，一个 Docker 镜像一旦构建完成，它的文件系统就是只读的。你不能 SSH 进去改一个配置文件然后说「这个镜像更新了」——不行，你得重新构建一个新镜像。

这个特性为什么重要？因为它保证了环境的一致性。你在测试环境验证通过的镜像，到了生产环境，理论上行为应该完全一致。如果镜像可变，那测试通过的东西到了线上可能就变了，这还怎么玩？

我举个例子：

# 错误的做法：打标签覆盖旧镜像
docker tag myapp:v2.5.3 myapp:latest
docker push myapp:latest   # 此时 latest 指向了 v2.5.3

# 过了一周，又构建了 v2.6.0
docker tag myapp:v2.6.0 myapp:latest
docker push myapp:latest   # latest 被覆盖了，v2.5.3 的 latest 引用丢失

你看，latest 标签就是一个「移动指针」。它指向的镜像一直在变，这就破坏了不可变性。我建议的做法是：永远不要在生产环境使用 latest 标签。每个部署都使用完整的版本标签，比如 myapp:v2.5.3-g1a2b3c4。

2.3 校验和（Checksum）原理：给文件做指纹鉴定

校验和，说白了就是给一个文件或数据算出一串「数字指纹」。哪怕文件只改了一个比特，算出来的指纹也会完全不一样。常用的算法有 MD5、SHA-1、SHA-256。现在业界标准是 SHA-256，MD5 和 SHA-1 已经被证明有碰撞风险，不建议用在安全场景。

校验和的工作原理其实很简单：

1. 输入：任意长度的数据（镜像层、安装包、配置文件）
2. 算法：一个单向哈希函数（比如 SHA-256）
3. 输出：固定长度的摘要（比如 64 个十六进制字符）

这个摘要就是校验和。它的两个关键特性是：

• 唯一性：不同输入几乎不可能产生相同输出（碰撞概率极低）
• 单向性：从摘要无法反推出原始数据

在镜像校验的场景里，我们通常会在镜像仓库里存储每个镜像清单（Manifest）的 SHA256 值。当你拉取镜像时，Docker 客户端会自动计算拉下来的数据的 SHA256，然后跟仓库里记录的比对。如果对不上，说明镜像在传输过程中被篡改或损坏了。

下面这张图展示了校验和在镜像拉取过程中的作用：

你看，整个流程其实就三步：拉取 → 计算 → 比对。但就是这简单的一步比对，能挡住绝大多数因网络劫持、存储损坏导致的交付事故。

2.4 三个概念如何串联起来

版本控制、镜像不可变性、校验和，这三者不是孤立的。它们共同构成了回滚保护的「信任链」：

• 版本控制 告诉你「回滚到哪个点」
• 镜像不可变性 保证「那个点的内容没变过」
• 校验和 验证「你拿到的确实是那个内容」

缺少任何一个环节，回滚保护都是空谈。没有版本控制，你找不到目标；没有不可变性，你找到的目标可能已经被污染；没有校验和，你无法确认目标是否完整。