最近 Node.js 官方宣布了一个重磅消息从 Node.js 27 开始将从每年发布两个大版本改为每年只发布一个大版本并且每个版本都会进入 LTS长期支持。这是 Node.js 发布机制诞生 10 年以来最大的一次调整。老模式有什么问题过去 10 年里Node.js 一直采用偶数版本进 LTS奇数版本不进的策略。比如 Node 20 是 LTSNode 21 不是Node 22 又是 LTS。听起来挺清晰但实际情况是大多数开发者和企业根本不碰奇数版本。这很好理解。你在生产环境跑着 Node 20下一个 LTS 是 Node 22中间的 Node 21 既没有长期支持又很快就 EOL生命周期结束谁会专门花时间升级到一个临时版本呢结果就是奇数版本变成了一个尴尬的存在它占用了维护者的精力却几乎没人用。而 Node.js 是一个以志愿者为主的开源项目同时维护 4-5 条发布线backport向旧版本移植修复的工作量非常大安全补丁的发布也越来越难以为继。简单说旧模式造成了三个核心问题资源浪费奇数版本投入了维护成本但采用率极低新手困惑奇偶版本的区别对新人来说不直观维护者压力多条发布线并行志愿者团队难以承受新模式长什么样从 Node.js 27 开始发布节奏变成这样阶段时间说明Alpha10 月 - 次年 3 月6 个月新的预览通道允许破坏性变更Current4 月 - 10 月6 个月正式发布进入稳定期LTS10 月起持续 30 个月长期支持接收安全修复EOLLTS 结束后不再维护一个版本从 Current 发布到 EOL总共获得36 个月的支持。举个具体的例子Node.js 27 的生命周期是这样的2026 年 10 月Alpha 阶段开始2027 年 4 月正式发布 27.0.02027 年 10 月进入 LTS2030 年 4 月EOL而 Node.js 26 将是旧模式下的最后一个版本2026 年 4 月发布10 月进入 LTS2029 年 4 月 EOL。版本号终于和年份对齐了新方案还有一个附带的好处版本号将和年份对应。Node.js 27 在 2027 年发布28 在 2028 年29 在 2029 年以此类推。未来你看到一个 Node.js 版本号就能大概知道它是哪一年的产物。这比之前的编号方式直观多了。Alpha 通道是什么你可能会问奇数版本没了谁来承担提前试新特性的角色答案是新引入的Alpha 通道。每年 10 月到次年 3 月Node.js 会发布 Alpha 版本。这些版本是经过签名和标记的正式构建产物不是 Nightly 那种未经测试的快照而且会通过 CITGMCanary in the Goldmine进行生态兼容性测试。CITGM 这个工具很有意思它会拿主流开源包的测试套件跑一遍看看新版本有没有把生态搞坏。如果某个热门库在新版本上挂了包作者会在正式发布之前收到通知有时间去适配。Alpha 通道的定位很明确适合库作者在 CI 中跑兼容性测试提前发现问题不适合生产环境使用对不同开发者的影响如果你只用 LTS 版本大多数人都是这样这次变化对你来说几乎是透明的。支持周期没缩短升级路径反而更清晰了。以前你需要跳过奇数版本现在每个版本都是 LTS不存在该不该升级的纠结。如果你是库作者需要注意把 Alpha 版本加进你的 CI 测试矩阵。越早测试越早发现兼容性问题。如果你只在 LTS 上跑测试等到用户升级时才发现 bug那就晚了。如果你是 Node.js 的贡献者维护负担会明显减轻。少维护一条发布线意味着更少的 backport 工作、更少的安全补丁分发压力。对于一个志愿者驱动的项目这一点非常关键。未来十年的发布节奏一览Node.js 27: 2026.10 Alpha → 2027.04 发布 → 2027.10 LTS → 2030.04 EOL Node.js 28: 2027.10 Alpha → 2028.04 发布 → 2028.10 LTS → 2031.04 EOL Node.js 29: 2028.10 Alpha → 2029.04 发布 → 2029.10 LTS → 2032.04 EOL Node.js 30: 2029.10 Alpha → 2030.04 发布 → 2030.10 LTS → 2033.04 EOL每年一个大版本节奏稳定版本号和年份对齐一目了然。一些值得关注的细节值得一提的是在 GitHub issue 的讨论中最初的提案其实建议把 LTS 时长从 30 个月缩短到 24 个月。但最终官方博客公布的方案保留了 30 个月的 LTS 支持期。这说明社区的反馈起到了作用维护团队在减轻负担和保障用户之间做了平衡。另外V8 引擎的更新节奏不会受影响。每个新版本发布时搭载的 V8 版本大约是 6 个月前的稳定版这个策略和之前一样。热点推荐Fastify 作者怒了AI 老是写烂代码他把多年 Node.js 经验打包成 Skill 全开源了规格驱动翻车了Augment Code 一篇长文直接开怼React 被反超的那一刻我看到了开源世界最大的泡沫Node.js 终于能打包成 exe 了华人工程师连下两城尤雨溪实测启动速度碾压 BunCursor 内部 35% 的 PR 已由 AI 自主完成你的工作方式落后了吗Docker 亲自下场了把 OpenClaw 关进沙盒你的 API 密钥再也不会裸奔了
Node.js 发布节奏大变！从此每年只发一个大版本，每个版本都是 LTS
最近 Node.js 官方宣布了一个重磅消息从 Node.js 27 开始将从每年发布两个大版本改为每年只发布一个大版本并且每个版本都会进入 LTS长期支持。这是 Node.js 发布机制诞生 10 年以来最大的一次调整。老模式有什么问题过去 10 年里Node.js 一直采用偶数版本进 LTS奇数版本不进的策略。比如 Node 20 是 LTSNode 21 不是Node 22 又是 LTS。听起来挺清晰但实际情况是大多数开发者和企业根本不碰奇数版本。这很好理解。你在生产环境跑着 Node 20下一个 LTS 是 Node 22中间的 Node 21 既没有长期支持又很快就 EOL生命周期结束谁会专门花时间升级到一个临时版本呢结果就是奇数版本变成了一个尴尬的存在它占用了维护者的精力却几乎没人用。而 Node.js 是一个以志愿者为主的开源项目同时维护 4-5 条发布线backport向旧版本移植修复的工作量非常大安全补丁的发布也越来越难以为继。简单说旧模式造成了三个核心问题资源浪费奇数版本投入了维护成本但采用率极低新手困惑奇偶版本的区别对新人来说不直观维护者压力多条发布线并行志愿者团队难以承受新模式长什么样从 Node.js 27 开始发布节奏变成这样阶段时间说明Alpha10 月 - 次年 3 月6 个月新的预览通道允许破坏性变更Current4 月 - 10 月6 个月正式发布进入稳定期LTS10 月起持续 30 个月长期支持接收安全修复EOLLTS 结束后不再维护一个版本从 Current 发布到 EOL总共获得36 个月的支持。举个具体的例子Node.js 27 的生命周期是这样的2026 年 10 月Alpha 阶段开始2027 年 4 月正式发布 27.0.02027 年 10 月进入 LTS2030 年 4 月EOL而 Node.js 26 将是旧模式下的最后一个版本2026 年 4 月发布10 月进入 LTS2029 年 4 月 EOL。版本号终于和年份对齐了新方案还有一个附带的好处版本号将和年份对应。Node.js 27 在 2027 年发布28 在 2028 年29 在 2029 年以此类推。未来你看到一个 Node.js 版本号就能大概知道它是哪一年的产物。这比之前的编号方式直观多了。Alpha 通道是什么你可能会问奇数版本没了谁来承担提前试新特性的角色答案是新引入的Alpha 通道。每年 10 月到次年 3 月Node.js 会发布 Alpha 版本。这些版本是经过签名和标记的正式构建产物不是 Nightly 那种未经测试的快照而且会通过 CITGMCanary in the Goldmine进行生态兼容性测试。CITGM 这个工具很有意思它会拿主流开源包的测试套件跑一遍看看新版本有没有把生态搞坏。如果某个热门库在新版本上挂了包作者会在正式发布之前收到通知有时间去适配。Alpha 通道的定位很明确适合库作者在 CI 中跑兼容性测试提前发现问题不适合生产环境使用对不同开发者的影响如果你只用 LTS 版本大多数人都是这样这次变化对你来说几乎是透明的。支持周期没缩短升级路径反而更清晰了。以前你需要跳过奇数版本现在每个版本都是 LTS不存在该不该升级的纠结。如果你是库作者需要注意把 Alpha 版本加进你的 CI 测试矩阵。越早测试越早发现兼容性问题。如果你只在 LTS 上跑测试等到用户升级时才发现 bug那就晚了。如果你是 Node.js 的贡献者维护负担会明显减轻。少维护一条发布线意味着更少的 backport 工作、更少的安全补丁分发压力。对于一个志愿者驱动的项目这一点非常关键。未来十年的发布节奏一览Node.js 27: 2026.10 Alpha → 2027.04 发布 → 2027.10 LTS → 2030.04 EOL Node.js 28: 2027.10 Alpha → 2028.04 发布 → 2028.10 LTS → 2031.04 EOL Node.js 29: 2028.10 Alpha → 2029.04 发布 → 2029.10 LTS → 2032.04 EOL Node.js 30: 2029.10 Alpha → 2030.04 发布 → 2030.10 LTS → 2033.04 EOL每年一个大版本节奏稳定版本号和年份对齐一目了然。一些值得关注的细节值得一提的是在 GitHub issue 的讨论中最初的提案其实建议把 LTS 时长从 30 个月缩短到 24 个月。但最终官方博客公布的方案保留了 30 个月的 LTS 支持期。这说明社区的反馈起到了作用维护团队在减轻负担和保障用户之间做了平衡。另外V8 引擎的更新节奏不会受影响。每个新版本发布时搭载的 V8 版本大约是 6 个月前的稳定版这个策略和之前一样。热点推荐Fastify 作者怒了AI 老是写烂代码他把多年 Node.js 经验打包成 Skill 全开源了规格驱动翻车了Augment Code 一篇长文直接开怼React 被反超的那一刻我看到了开源世界最大的泡沫Node.js 终于能打包成 exe 了华人工程师连下两城尤雨溪实测启动速度碾压 BunCursor 内部 35% 的 PR 已由 AI 自主完成你的工作方式落后了吗Docker 亲自下场了把 OpenClaw 关进沙盒你的 API 密钥再也不会裸奔了
