Node.js 发布节奏十年没动过，这次悄悄改了——奇偶版本退役、每个版本都是 LTS，单版本支持周期固定 36 个月

铁锈·Rust工具链 内容创作者 2026-10-02 75 阅读

Node.js 从 2026 年 10 月起改为一年只发一个大版本、每个版本都进 LTS，沿用十年的奇偶版本规则正式退役：首个新节奏版本 Node 27 的 Alpha 通道就在本月开启，单版本从 Current 发布到 EOL 固定支持 36 个月（6 个月 Alpha + 6 个月 Current + 30 个月 LTS），版本号从此等于年份——27 就是 2027 年的版本。

十年老规则到底卡在哪

旧规则是 io.js 合并时期定下的，官方原话是当时「对企业需求的一次有依据的猜测」，一用就是 10 年：一年发两个大版本（4 月和 10 月），偶数版 10 月转 LTS、拿 30 个月支持，奇数版只有约 6 个月寿命、永远进不了 LTS。

十年数据跑下来，三个问题全暴露了：

  • 奇数版几乎没人用。 Node.js TSC 主席 Matteo Collina 的说法是非 LTS 版本「barely get used」，多数企业直接跳过 21、23、25，只等下一个 LTS——但维护这些版本的志愿者工作量一分不少。
  • 维护线太多撑不住。 安全补丁要在 4~5 条并发 release line 上分别 backport、测试、协调，而 Node.js 主要靠志愿者业余时间运转。TSC 成员 Marco Ippolito 提到，Node 22 和 Node 26 已经分化到单个 commit 在两者间移植都很困难。
  • 新人搞不懂奇偶规则。 「下一个版本是奇数还是偶数」本身就成了生态入门障碍。

2025 年 7 月，TSC 成员 Rafael Gonzaga 正式提出改版提案（nodejs/Release#1113）；参与设计过旧规则的 James Snell 也承认，十年前那套方案「完全基于当时的企业采用周期」，之后再没重新审视过。2026 年 3 月 10 日，官方博客以《Evolving the Node.js Release Schedule》宣布改版，公告在 X 上拿到 2100+ 点赞。

新规则：版本号就是年份

对比项 旧模型（到 Node 26 为止） 新模型（Node 27 起）
每年大版本 2 个（4 月 + 10 月） 1 个（4 月）
LTS 资格 只有偶数版 每个版本都是
奇数版 约 6 个月寿命，永不 LTS 退役
早测通道 短命奇数版 独立 Alpha 通道（10 月-次年 3 月）
版本号 顺序递增，含义不透明 等于 Current 发布年份
单版本总支持 LTS 版约 30-36 个月 固定 36 个月

两条时间线并行跑一段：

  • Node 26（旧模型最后一版）： 2026 年 4 月发布 → 2026 年 10 月进入 LTS → 2029 年 4 月 EOL
  • Node 27（新模型第一版）： 2026 年 10 月 Alpha 开启 → 2027 年 4 月发布 27.0.0 → 2027 年 10 月进 LTS → 2030 年 4 月 EOL

往后每年如此：28 在 2027 年 10 月开 Alpha、2028 年 4 月发布，29、30 依次类推。版本号和年份锁定之后，「这个运行时多老了」变成一眼能读出来的算术题——Node 27 是 2027 年的版本，加 36 个月就是它的 EOL，和 Ubuntu 24.04 读出「2024 年 4 月」一个道理。企业内部那条执行了十年的「奇数版不进生产」规定，也可以直接删了。

需要注意的是支持窗口本身没有缩短：LTS 仍是 30 个月，迁移重叠期还在，变的是「要不要跳过某个版本」这个判断题——它不复存在了。

Alpha 通道：给库作者的 6 个月预警期

奇数版退役会留下一个真空：以前库作者靠短命奇数版提前撞见破坏性变更，现在谁来补这个预警位？答案是新的 Alpha 通道，10 月到次年 3 月运行，明确允许 semver-major 变更，版本号用标准 semver 预发布格式（如 27.0.0-alpha.1）。

它和 Nightly 构建有本质区别：Alpha 是签名、打 tag 的正式产物，并经过 CITGM（Canary in the Goldmine）测试——CITGM 会拿主流开源包的测试套件在新版本 Node 上跑一遍，生态被搞坏时包作者会在正式发布前收到通知；Nightly 只是从 main 分支自动构建的未测试快照。Alpha 还有一个附带收益：V8 更新可以更早落进周期（正式版本仍保持约 6 个月以内的 V8 滞后）。

官方对这个通道的措辞相当直接：如果你只在 LTS 上测试，你报告 bug 的时机将和用户受影响的时机完全相同——这正是 Alpha 要避免的局面。所以它面向库作者和 CI 管道，不面向生产。

落到 CI 上，改动就是矩阵加一列：

# before：只测 LTS，破坏性变更要等它砸到用户头上才发现
strategy:
  matrix:
    node-version: [20.x, 22.x, 24.x]

# after：本月起把第一个 Alpha 拉进矩阵，挂了不阻塞主干但必须看得见
strategy:
  matrix:
    node-version: [24.x, 26.x, 27.0.0-alpha.1]
  fail-fast: false

本地想先踩一脚也只要一行：

nvm install 27.0.0-alpha.1   # 或 fnm install 27.0.0-alpha.1

同时把 package.json 里的 engines 基线检查一遍——写 >=20 的项目要注意 Node 20 已于 2026 年 4 月 30 日 EOL，容器基础镜像还钉在 node:20 的更要换。

三类人这个月各自要做什么

只用 LTS 的团队： 官方对你的原话是「除了版本号几乎没什么变化」。动作只有两个：删掉内部的奇数版跳过规则，核对现有版本的 EOL 日历——Node 22 到 2027 年 4 月、Node 24 到 2028 年 4 月、Node 26 本月进 LTS、2029 年 4 月 EOL。

跟踪 Current 的团队： 一年一次的固定升级窗口（4 月），早测工作从「等奇数版」搬到 Alpha 通道，评估节奏要跟着收紧。

库作者（官方唯一明确要求行动的群体）： 本月就把 27.0.0-alpha.1 加进 CI 矩阵。Alpha 允许破坏性变更，这 6 个月就是你替用户挡刀的窗口；只在 LTS 上测，等于把发现问题的责任转嫁给了下游。

本周可以落地的三步

  1. 给 CI 矩阵追加 27.0.0-alpha.1，配 fail-fast: false，先让它跑起来看见结果；
  2. 扫一遍 engines 字段、Docker 基础镜像和版本管理器配置，清掉已 EOL 的版本；
  3. 把内部升级文档里「隔一年跳一个大版本」的段落，改写成「每年 4 月一个新版本，全部 LTS，版本号即年份」。

下一个真正的决策点在 2027 年 4 月（27.0.0 Current 发布）和 2027 年 10 月（Node 27 转 LTS），在那之前，本月的 Alpha 就是所有库作者的主战场。

参考链接：

# 知识# 编程# 资讯

评论区

0 条评论

登录后可评论。

铁锈·Rust工具链 75 阅读