Node.js 一年一个大版本：从 v27 起，所有版本都是 LTS

预计阅读时间：8 分钟

从 2026 年 10 月的 Node 27 开始，Node.js 将告别"半年一个大版本、偶数 LTS、奇数实验"的双轨节奏，改为每年只发布一个主要版本——并且每个版本都进入长期支持。同时新增 Alpha 通道，供早期特性尝鲜。这一调整直指维护成本和用户实际节奏之间的长期矛盾。

双轨制是怎么走到尽头的

过去多年，Node.js 每年推出两个大版本：偶数版本（如 18、20、22）进入 LTS，获得 30 个月支持；奇数版本（如 17、19、21）只维护 6 个月，本质上是非稳定实验线。这套机制的本意是让新特性快速落地、社区尽早反馈，再由 LTS 线兜住生产环境。

但现实是：维护两条线对核心团队的压力越来越大。每个 LTS 版本需要独立的安全补丁、bug 修复和 V8 引擎跟进，而奇数版本的生命周期太短，很多用户干脆跳过，导致反馈量不足。企业用户也常困惑——"我们该跟偶数还是奇数？"决策成本被双轨制放大了。

一年一个版本、全部 LTS，意味着每个版本都能获得完整的长期支持窗口，维护焦点集中，用户升级路径也更清晰。

Alpha 通道：实验性特性的新出口

取消奇数版本后，实验性特性去哪？答案是 Alpha 通道。Alpha 版本将作为独立发布线，包含尚未稳定的新 API、V8 实验特性或架构变更。它不保证 API 兼容性，也不进入 LTS，定位接近 Chrome 的 Canary 或 Rust 的 nightly。

这对开发者的影响是：

生产环境：只用正式 LTS 版本，节奏从"每 6 个月判断要不要升"变成"每年评估一次"。
尝鲜和工具链开发：可以跑 Alpha 版本做早期验证，但必须接受 API 随时可能变动。
库维护者：在 Alpha 上测试兼容性，在 LTS 上发布稳定支持。

升级节奏怎么调整：一个可操作的检查方案

版本节奏变了，项目里的 Node 版本约束和 CI 配置也需要同步。下面是一套可以直接用的版本检测和升级提醒脚本。

用 nvm 管理新节奏下的版本切换

# 查看当前可用的 LTS 版本（现有节奏下）
nvm ls-remote --lts

# 安装最新的 LTS 版本
nvm install --lts

# 从 v27 开始，所有正式版本都是 LTS，安装方式不变
# 但如果你想尝鲜 Alpha 通道（假设未来 nvm 支持 alpha 标签）：
# nvm install node/alpha   # 注意：Alpha 不保证稳定，仅用于本地测试

# 在项目中锁定特定 LTS 版本
nvm use 22
# 将版本写入 .nvmrc，团队统一
echo "22" > .nvmrc

package.json 的 engines 字段：声明你的最低支持版本

{
  "name": "my-service",
  "version": "1.4.0",
  "engines": {
    "node": ">=22.0.0"
  },
  "scripts": {
    "check-node": "node -e \"const v=process.versions.node;const major=parseInt(v.split('.')[0]);if(major<22){console.error('Node '+v+' 不满足最低要求 >=22，请升级');process.exit(1)}else{console.log('Node '+v+' 检查通过')}\""
  }
}

运行 npm run check-node 即可在 CI 或本地启动前拦截不兼容的 Node 版本。

CI 配置示例：GitHub Actions 按新节奏覆盖 LTS 版本

name: CI
on: [push, pull_request]

jobs:
  test:
    strategy:
      matrix:
        # v27 起每年一个 LTS，矩阵只需覆盖最近的 2-3 个 LTS
        node-version: [22, 24]
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}
      - run: npm ci
      - run: npm test

v27 之后，你只需要在矩阵里保留最近两三个 LTS 版本号，不再需要纠结"要不要测奇数版本"。

对你的项目意味着什么

这一变更带来几个实际影响，值得提前规划：

升级频率降低，但每次升级的跨度可能更大。 一年一个版本意味着每个版本承载的变更量比过去半年版更多。升级时的 breaking change 密度可能上升，建议在 LTS 发布后的前三个月内完成兼容性验证——这段时间社区补丁最活跃。

版本选择不再有歧义。 不存在"偶数稳、奇数险"的判断，每个正式版本都值得上生产。决策简化为"用最新的还是前一个 LTS"。

Alpha 通道需要明确的隔离策略。 Alpha 只应在独立环境（如 Docker 容器或 CI 的 experimental job）中运行，不要和生产依赖混用。可以在 CI 中加一个可选的 experimental job：

  experimental:
    continue-on-error: true
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 'alpha'  # 假设未来支持
      - run: npm ci || true
      - run: npm test || true

continue-on-error: true 确保 Alpha 失败不阻塞主流程，但你能提前看到兼容性问题。

库维护者的支持窗口更清晰。 过去需要同时支持当前 LTS 和前一个 LTS（比如 20 和 22），新节奏下仍然是两个活跃 LTS 并存，但重叠期更长，升级节奏更从容。

时间线与行动清单

2025 年 10 月：Node 26 按现有节奏发布，进入 LTS。
2026 年 4 月：最后一个奇数版本 Node 27 的前身按旧节奏发布（如果仍有计划），但随后切换到新节奏。
2026 年 10 月：Node 27 作为新节奏的首个年度 LTS 版本发布，Alpha 通道同步上线。

现在可以做的事：

检查 package.json 的 engines 字段，确认是否还写着过时的版本范围（如 >=14），收紧到当前 LTS。
清理 CI 矩阵中不再需要的奇数版本测试。
在团队内统一 .nvmrc，锁定当前 LTS 版本。
如果你的工具或框架依赖 Node 内部 API（如 native addon），提前在 Alpha 通道验证兼容性。