红帽今年六月的全球峰会上，发布了一堆 AI 新品，但在企业 IT 圈里讨论度最高的，是一个不太起眼的新东西：RHEL Forever，直白点说就是“RHEL 永久支持”。客户一直交钱，红帽就一直给旧版本系统打补丁，不设终止日期。消息传开后，社区立刻分成了两派：一派说这是等了很多年的定心丸，另一派则冷笑，说这就是传说中的“金螺丝刀”。
先搞清楚，这是个什么东西
RHEL Forever 的中文名是“RHEL长生命周期增强包”。知乎该服务没有预设的终止日期，只要客户持续付费，就能持续获得关键安全补丁、紧急 bug 修复和 7×24 小时技术支持，将旧版本的 RHEL 长期维持在安全稳定状态。知乎
红帽为什么要做这么一门生意
红帽自己的说法是，这一增强包可以满足部分企业客户对业务稳定性的要求，延长相关基础设施的维护支持。知乎展开说就是：操作系统的官方支持周期，往往短于企业应用真正要服役的时间，不少公司因为系统停止支持被迫做平台迁移，代价高昂，而更长的支持周期能让 IT 管理者将软件生命周期与长期硬件投资、复杂的合规监管节奏同步，而非被强制升级时间表牵着走。知乎
要理解 Forever，先看 RHEL 原来的生命周期怎么算
RHEL 8、9、10 的默认生命周期是 10 年，分成全支持、维护支持和延长生命三个阶段。Red Hat 官方文档用大白话说就是：前五年全力支持，后五年以维护为主，之后进入收尾期。
在 10 年之外，红帽又叠了两层付费延期：延长生命周期（ELC）给符合条件的小版本再续六年；如果还不够，Long-Life Add-On 按年计费、逐年续订，合格小版本的补丁覆盖最长能到 14 年甚至更久。Red Hat 官方文档这次官宣的 Forever，本质就是把最后那层“按年续”做成了不设上限的长期生意。但要注意官方规则的另一面：一旦中途停止续费，已发布的内容只会进入归档通道，不再有新的更新、bug 修复和 CVE 覆盖。换句话说，断供那天，手里的系统就成了标本。在官方公布的 RHEL 10 生命周期图上，橙色的 Long-Life 段被一路画到了 2043 年。
为什么有人喊它“金螺丝刀”
“金螺丝刀”不是网友造出来的词，它来自一段真实的行业记忆：20 世纪 90 年代末，小型机厂商 Wang 的渠道伙伴全部退出，原厂成为唯一支持来源后，立刻大幅抬高服务价格，甚至上门排查就要收四位数美元的出场费——因为此时只有原厂的人能碰机器，否则保修失效。知乎道理很简单：当维修师傅只剩一个，维修费就只能由他开口。
红帽今天当然可以承诺不会这么干，但企业买的不是今天的红帽，是未来二三十年的红帽。一旦客户深度依赖某个旧版本、迁移成本高到无法承受，供应商就掌握了绝对的定价权。知乎今天看似合理的年费，十年后可能逐年上涨，而企业别无选择——这正是反对者最担心的一幕。
还有一笔隐性账：技术债。系统“躺着不动”的每一年，都是在给未来的迁移加码，真到十年、二十年后想换平台时，技术栈可能早已断层，迁移成本反而比按节奏定期升级更高。安全也要分场景看：对核电站、医疗设备这类极度厌恶变更的系统，“不变”本身就是安全，通用电气加拿大分公司 2013 年还在为运行核电站的 PDP-11 系统招募维护人员，合同一签就到 2050 年；但对面向互联网的业务系统，守着古老内核等补丁，反而可能是最大的风险敞口。
不过，这扇门也不是唯一的门
判断要不要被“永久绑定”，得先看看有没有退出通道。RockyLinux和AlmaLinux是CentOSLinux停更后最主要的两个RHEL二进制兼容发行版，均提供10年长期支持和免费使用的企业级体验。知乎再加上 Oracle Linux 这类有厂商背书的兼容版，RHEL 生态其实一直存在“免费替身”。这意味着金螺丝刀的故事有一个重要的约束条件：如果红帽真把年费涨到离谱，企业理论上可以迁去兼容发行版，而不是坐地挨宰。但也要清醒：免费替身没有红帽式的 7×24 责任兜底，迁移测试、合规审计、出事之后的问责，都得自己扛。退出门存在，不代表退出是免费的。
对中国企业，还有一层变量
2026年4月9日，全球企业级开源巨头红帽（Red Hat）通过内部邮件正式确认：停止在中国的全部工程研发活动，419名研发人员将在7月31日前全部离职。知乎对已经跑着 RHEL 的国内企业来说，评估 Forever 这类长期订阅时，红帽本地研发与支持力量的收缩，是必须计入的变量；与此同时，龙蜥、openEuler 等国产路线也已经进入不少企业的备选清单。绑定一个“永久服务”之前，先看清服务方未来十年在本地的投入，不亏。
到底谁该买，谁不该碰
适合认真考虑的，是典型的“变更即风险”场景：金融核心、能源电力、医疗、工业控制这类强监管行业，核心系统长期跑在生产环境里，一动不如一静，合规审计又要求厂商支持背书，硬件折旧和软件迭代的节奏天然对不齐——对它们来说，花钱买“不用动”，是一笔理性的账。
不适合的也很清楚：面向互联网的业务系统、有成熟升级能力的团队、预算敏感的中小团队。对这类用户，按节奏滚动升级的总成本，大概率低于“永远交租”；与其为不变付费，不如把升级做成常规动作。
决定之前，先做三件事
把系统盘成三类：不能动的、不必动的、应该动的。Forever 只值得花在“不能动”的那一小撮上，千万别全量打包买单。
按五年窗口算一笔总账：把续订年费、中途退出的迁移测试成本、兼容发行版的替代方案放进同一张表，再和“按节奏升级”的投入比一比。
别让升级能力生锈：无论买不买，都保持团队的版本演练和兼容性测试节奏，退出通道才不会变成摆设。
最后留个问题给搞基础设施的朋友：如果你的核心系统可以“永远不升级”，你会选择为稳定买单，还是坚持定期换代的纪律？评论区聊聊。
