Node.js 2026年起发布策略调整：每年一个主版本，告别奇数版本

从 27.x 版本开始，Node.js 将从每年发布两个主版本，调整为每年发布一个主版本。

Node.js 官方为什么要做这个改变？具体会发生哪些变化？这次调整对不同角色的用户意味着什么？

如果你正在使用或关注 Node.js 的发展，这篇文章将为你理清思路。

总结：如果你本来就只升级 LTS 版本，那么几乎没有影响（除了版本号变化）。LTS 支持周期基本不变，而且现在每个版本都会成为 LTS。

为什么要做这个改变？

首先，官方明确表示，当前的发布策略已经有10年历史，诞生于 io.js 合并时期。当时的目标是 “基于经验猜测企业需要什么”。

但现在，官方拥有了10年的真实使用数据：

• 奇数版本几乎没人用
• 大多数用户只等 LTS
• 奇偶版本规则让新用户困惑
• 很多企业直接跳过奇数版本

其次，维护成本已经让社区“扛不住了”。Node.js 主要由志愿者维护，他们的工作包括：

• PR review
• 安全修复
• 发布版本
• backport（向旧版本移植修复）

核心问题在于：同时维护 4~5 条发布线 已经难以持续。每多一条版本线，回溯修复的复杂度和安全维护成本都会指数级增加。

因此，这次调整的本质是：减少维护负担，把精力集中在真正被使用的版本上。

会发生哪些变化？

从2026年10月开始，新的发布策略如下：

• 每年发布一个主要版本（4月），10月进行 LTS 推广。
• 每个版本都会成为 LTS 版本，不再区分奇偶数——Node.js 27 将成为 LTS 版本。
• Alpha 通道用于早期测试，允许进行主版本号变更。
• Alpha 版本控制遵循语义化版本控制预发布格式（例如，27.0.0-alpha.1）。
• 版本号与其首次发布的年份一致。例如：2027年发布27.0.0，2028年发布28.0.0。
• 减轻发布者的负担。

具体的阶段划分和时间周期如下表所示：

我们可以通过下面的时间线图来直观地理解整个流程：

一个版本从 Current 发布到 EOL，总支持周期为 36个月。Node.js 27 将是新发布计划下的第一个版本。

官方还提供了未来十年的详细版本预览表格：

对用户的影响

• 对于日常开发者：可以说几乎没有感知。大多数人本就只使用 LTS 版本，而这次调整并没有缩短支持周期。过去你需要刻意避开奇数版本，纠结“要不要等下一个 LTS”，现在这个问题被彻底消除了——每一个版本最终都会进入 LTS，升级路径变得更清晰、更简单。

• 对于库作者或 npm 包维护者：这次变化需要重视。Node.js 把原本“隐性存在”的破坏性变更风险前置到了 Alpha 阶段，未来的兼容性问题会更早暴露。如果你仍然只在 LTS 版本上做测试，问题可能会在用户升级后才爆发。因此，更合理的做法是把 Alpha 版本纳入 CI 测试体系，尽可能在发布前发现并解决问题。

• 对于 Node.js 的贡献者或维护者：这次调整意义更深。减少一条发布线，意味着整体的维护复杂度显著下降。对于一个以志愿者为主导的开源项目来说，这能让社区更集中地支持用户实际使用的版本，是关乎项目长期可持续性的关键一步。

总而言之，这次调整不仅是发布策略的改变，更是 Node.js 基于过去十年的实践经验，做出的一次现实选择：让真正被使用的版本路径变得更简单，把有限的社区精力用在最有价值的地方。想了解更多关于技术架构与开发的深度讨论，欢迎访问我们的 云栈社区。