Node.js 宣布了重大发布调整

从 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 在长期发展中做出的一次现实选择：让真正被使用的路径变得更简单，把有限的精力用在更有价值的地方。

以上关于Node.js 宣布了重大发布调整的文章就介绍到这了，更多相关内容请搜索码云笔记以前的文章或继续浏览下面的相关文章，希望大家以后多多支持码云笔记。