CentOS Stream 大版本升级

从 CentOS Stream 9 换到 CentOS Stream 10 属于跨大版本的动作。「能不能做、官方给不给路径」必须先查证，再谈怎么排期——本页刻意把查证结论与通用评估流程分开写，两者不要混在一起当步骤用。

升级窗口的事实依据

官方下载页在 CentOS Stream 9 与 CentOS Stream 10 两个区块各给出一行 End-of-life：Stream 9 为 2027-05-31（对应 RHEL 9 full support 阶段结束），Stream 10 为 2030-05-31（对应 RHEL 10 full support 阶段结束）。这两个日期就是排升级窗口时唯一可引用的事实依据。

官方升级路径的核查结论

本次核对未取得官方升级路径。 也就是说，本轮没有找到可引用的官方说明来回答三个问题：官方是否支持从 Stream 9 升到 Stream 10、推荐用什么方式、存在哪些限制。

因此本页不提供任何升级命令、工具或分步操作。把「换仓库配置再同步软件包」这类二手经验写成流程，等于把社区经验伪装成官方路径，本页一律不写。要推进这件事，只能以官方文档与官方渠道的当前内容为准。

升级前评估：四项通用动作

无论最终走哪条路径，下列四项都属于通用工程动作（本页整理，不是官方条款）：

备份与快照：系统卷做快照、数据做可验证的备份，并实际恢复一次确认备份可用；
应用兼容盘点：列出业务依赖的软件与版本、外部集成点与硬件驱动，逐项确认在新大版本上是否有对应物；
准备回滚点：明确回滚的触发条件、由谁执行、需要多久，并把它写进变更单；
并行验证：用一套与生产同构的并行环境先跑通业务，再决定是否动生产。

中断与回滚的通用原则

跨大版本的动作一旦中断，最常见的麻烦不是「装不上」，而是状态不明。通用原则只有三条：

没有回滚点就不动手：回滚点是这类变更的准入门槛，而不是出事后才去找的东西；
中断后先取证再决策：现象、日志与当前状态先记录下来，再决定继续、重试还是回退；
不叠加变更：一次只推进一件事，避免把版本动作和配置调整塞进同一个窗口。

更新失败的具体分类与回退做法见滚动更新故障排障；起不来时先看 CentOS Stream 启动排障。

常见误解

「支持窗口还早，可以慢慢来」：窗口再长也是有限的，评估与验证要提前排，别把工作压到不可协商的时间点上；
「社区有教程就等于官方支持」：教程描述的是作者环境下的结果，与「官方是否支持这条路径」是两件事；
「升级中断就再升一次」：状态不明时的重复尝试会扩大影响面，先取证与回退，再谈重试；
「小版本经验可以直接套用到大版本」：跨大版本牵动整条软件栈，不能按小版本更新的经验估算风险。