Win11 24H2开始更新机制再进化:引入检查点累积更新机制

在 Windows 11 24H2 和 Windows Server 2025 及更高版本中，微软引入了全新的检查点累积更新（Checkpoint Cumulative Updates, CCU）机制。这种创新方法通过「增量python差异」技术，使更新体积更小、安装更快、更具可持续性，从android而节省部署时间、带宽和存储空间，保持系统最新和安全。而且无需你进行任何额外操作。

新机制会创建检查点（Checkpoint）作为未来更新的基准，而不是直接打包所有变更。这种新的更新机制带来了 3 大优势：

• 为 Windows 设备提供更小的补丁包下载。
• 为普通用户和 IT 管理员实现更可持续的更新分发。
• 改善年度功能更新体验，如 23H2、24H2。

原本的 Windows 更新机制

• 传统上，Windows 11 采用累积更新（Cumulative Updates, CU）方式，从操作系统 RTM 时开始累积构建。月度 CU 包含了自 RTM 以来的所有变更，以二进制差异的形式呈现，这些差异是基于 RTM 版本的系统文件计算得出的。
• CU 通常会被打包成一个单一的.msu文件，随着时间推移不断增大。无论是个人用户还是在组织中分发，都需要下载或缓存整个文件，从而导致存储和带宽的浪费，并且需要较长时间来下载和安装。
• 在 Windows 11 21H2 版本中，微软引入了「范围读取」技术，来减小补丁的下载量。这种技术只会下载php和安装缺失的二进制差异文件，这些差异文件是通过比较当前和 RTM 版本的系统文件计算得出的。

检查点累积更新机制

在 Windows 11 24H2 和 Windows Server 2025 中，微软引入了检查点累积更新（CCU）概念：

• 新机制允许 CU 被标记为「检查点」，作为后续更新的新起点。后续 CU 的二进制差异将与新的「检查点」中的系统文件版本进行比较，而不是与 RTM 比较。系统可以使用文件级去重技术，仅下载后续更新中的增量文件。
• 在 Windows 生命周期内，微软可能会定期将某些 CU 标记为「检查点」。之后的更新将包含两个部分：
  • 与检查点相关的更新包文件
  • 包含上一个检查点增量的二进制差异更新包文件
• Windows 11 24H2 的 Windows python11 服务堆栈（Servicing Stack）能够智能地合并所有检查点，并且只下载和安装当前设备上缺失的内容。

举个例子：假设你的设备刚安装了一个被标记为检查点的更新。那么下一次更新时，系统只需要下载自该检查点以来发生变化的部分，而不是自 RTM 发布以来的所有变化。这就好比你只需要接着写日记，而不是重写整本日记本。

CCU 机制仅适用于 Windows 11 24H2、Windows Server 2025 及更高版本。Windows 11 或 10 将继续沿用现有的累积更新方式。

如何管理新的累积更新

• 对于使用 Windows 更新、Windows Update for Business、Windows Autopatch 或 WSUS 来管理系统更新的普通用户或 IT 管理员来说，新的 CCU 机制不会影响js现有的工具和补丁分发流程，不需要做任何改变。新的更新机制将以改进后的普通月度更新的形式呈现。
• 对于从 Microsoft Update Catalog 获取更新的用户，某个月度更新可能会包含多个可供下载的更新包文件。这是因为每个检查点都会有一个对应的文件，此外还有一个包含自最新检查点以来所有累积变更的文件。你可以使用现有的部署工具按顺序安装这些文件。
• 如果你使用的是 Windows 10 或 Windows 11 24H2 之前的版本，更新过程不会受到影响。

想当初，就是为了简化和统合补丁分发，微软才在 Windows 10 中引入了累积更新机制，一扫「古早」每个 Windows 更新都是独立软件包的繁琐。简单来说，就是通过牺牲体积换复杂度。

好不容易走到现在，又要用复杂度来换体积，又走回去了，这是要搞哪样？这是完美继承了微软「改名逛人」的基因？