Compose 升到 v5.5 后，第一次 up 会把已有容器重建一遍

信息源：Docker Compose 的 release notes 与官方版本历史。

• 仓库：
• Releases：
• 版本历史：

v5 跳过 3.0/4.0，功能上与 v2 一致

Compose v5 发布于 2025-12。版本号从 2 直接跳到 5，跳过 3.0 和 4.0，原因是避免与遗留的 compose 文件格式 2.x / 3.x 混淆——如果出现「Compose 3.0」，很容易被理解成文件格式的又一次迭代。

功能上，v5 与 v2 一致。这不是一次功能重写，v5 的主要增量在下面两节。

Go SDK：把 Compose 能力嵌进应用

v5 引入了官方 Go SDK。可以 load、validate、管理多容器，也就是在自己的应用里读取并校验 compose 文件、驱动多容器编排，不必再依赖 CLI 子进程去做同样的事。

对需要把编排能力嵌进平台侧、控制面或流水线工具的场景来说，这是 v5 相对 v2 的实际差别。

同一版本里，v5.0 移除了内部 builder，构建改为委托给 Docker Bake——与 docker build 走同一条构建路径。

v5.6.0 的 jobs：目前只有手动触发

当前版本 v5.6.0（2026-10-02）新增了对 jobs 的部分支持。

限制很明确：目前只支持手动触发，定时 job 尚未可用。完整支持要等 Docker Engine 侧合入相关改动。也就是说，现在还不能把 Compose 的 jobs 当作完整的调度方案使用。

v5.5.0 重做了 digest 对账

v5.5.0（2026-09）重做了镜像 digest 的对账逻辑。

升级到 v5.5 之后第一次执行 compose up，可能看到已经存在的容器被重建一遍。原因是：这些容器的 digest 会用新逻辑重新评估，评估结果与旧逻辑留下的记录不一致，对账据此判定需要更新，容器于是被重新创建。

这是新逻辑生效后的预期行为，不是升级引入的回归。反过来说，升级后第一次 up 的重建规模，与本地已存在的容器数量直接相关。

pull_policy 有了刷新窗口

同一版本里，compose pull 开始遵守 pull_policy 的刷新窗口：daily、weekly、every_N。

刷新窗口参与判断之后，拉取动作是否真的执行，会按策略的时间窗来决定，而不是每次调用都无条件取新镜像。对用 pull_policy 控制镜像新鲜度的流水线，这是需要留意的语义变化。

init 容器与 reconcile 算法

更早的版本还引入了原生 init 容器支持，以及新的期望态/观测态 reconcile 算法。v5.5 对 digest 对账的调整，是这套 reconcile 思路在镜像层面的一次落地。

要在多容器编排里用 init 容器，现在可以直接写进 compose 配置，不必再靠 entrypoint 脚本绕。