Node.js 26 与 24 LTS：双轨发布机制下的运行时选型指南
开源的跨平台 JavaScript 运行时环境，由 OpenJS 基金会以开放治理模式支持。
秒懂
- 它是什么？
- Node.js 是跨平台 JavaScript 运行时，其 Current 与 LTS 双轨制决定了不同用户应选择不同版本。本文基于官方仓库与发布记录，分析其发布节奏、构建方式、安全验证流程，并指出升级成本与适用边界。
- 适合谁用？
- Node.js 适合绝大多数 JavaScript 服务端与工具链场景，但选型必须基于版本轨道而非最新版本号。生产环境应优先选用偶数主版本的 LTS 线路，例如当前的 v24 'Krypton'，它提供 12 个月 Active LTS 加 18 个月 Maintenance，总计 30 个月支持窗口。
- 能商用吗？
- 请先确认。这个仓库使用的许可证不在我们自动归类的范围内，商用前请阅读仓库里的 LICENSE 文件。
- 还在维护吗？
- 在维护。仓库最近一次提交在 1 天前。
- 用什么语言写的？
- 主要是 JavaScript（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月14日）和我们的分析，不构成法律意见。
开源项目深度解析
一个运行时，两套时钟
Node.js 不是单一版本线。它同时维护 Current 与 LTS 两条轨道，两者节奏完全不同。Current 版本每 6 个月发布一个主版本，分别在四月和十月。十月发布的版本支持期只有 8 个月，四月发布的版本则在同年十月转为 LTS。偶数主版本才会进入 LTS，奇数主版本永远停留在 Current 轨道。这个设计把新功能试验与生产稳定需求分开。LTS 线路获得 12 个月 Active LTS 支持，再追加 18 个月 Maintenance，总计 30 个月。Maintenance 阶段只修安全问题和严重缺陷，不再添加功能。对于需要长期运行的服务，这意味着你选择的版本号决定了你的维护窗口长度。
Current 与 LTS 的实质差异
两者的差异不只是支持时长。Current 版本允许破坏性变更，LTS 则明确不引入破坏性变更，除非特殊情况。官方 README 的原话是 LTS 线路“没有破坏性变更或功能添加，除非某些特殊情况”。这意味着生产环境升级 LTS 时，依赖兼容性风险远低于 Current。但 LTS 也有代价：你拿不到新 API，直到它们进入下一个偶数主版本。例如 v24 'Krypton' 是当前 LTS，而 v26 是 Current。如果你需要 v26 中的新特性，就必须接受 Current 轨道的不稳定性。对于库作者，支持 Current 意味着每 6 个月就要适配一次可能的破坏性变更。对于应用团队，锁定 LTS 版本可以减少升级频率，但也要承受功能滞后。
从源码构建：门槛与平台限制
README 指向 BUILDING.md 获取构建说明，但该文件内容未在提供材料中展开。可以确认的是，Node.js 支持从源码构建，并且 README 提到“受支持的平台列表”也在 BUILDING.md 中。这意味着并非所有平台都能得到官方构建支持。如果你使用非主流操作系统或 CPU 架构，从源码编译可能是唯一途径，但你需要自己处理依赖工具链。一个实际建议是：先检查官方下载页面是否提供你的平台预编译二进制，如果没有，再读 BUILDING.md 确认构建依赖。构建 Node.js 不是简单的 ./configure 加 make，它涉及 Python 工具链、C++ 编译器版本等要求。对于没有 C++ 构建经验的团队，直接使用官方二进制更稳妥。
二进制验证：签名与校验的完整链路
下载 Node.js 二进制后，官方提供了完整的验证流程。下载目录中包含 SHASUMS256.txt.asc 文件，里面有 SHA256 校验和以及发布者的 PGP 签名。验证步骤在 README 中有明确命令：先用 curl 从 nodejs/release-keys 仓库获取受信任的 keyring，然后用 gpgv 验证签名，最后用 shasum 检查文件完整性。整个过程需要三个工具：curl、gpgv、shasum。如果你跳过签名验证，只做 SHA 校验，那么你信任的是下载服务器的安全性，而不是发布者的身份。对于安全要求高的环境，比如金融或医疗系统，这个验证步骤不应省略。注意 gpgv 与 gpg 不同，它只做验证，不导入密钥，适合自动化脚本。
Nightly 版本：谁该用，谁该躲
除了 Current 和 LTS，Node.js 还发布 Nightly 版本。这些版本从 Current 分支每 24 小时构建一次，前提是当天有代码变更。目录命名格式包含版本号、UTC 日期和提交 SHA，例如 v22.0.0-nightly20240424ddd0a9e494。README 明确警告“谨慎使用”。Nightly 版本没有语义化版本承诺，没有签名保证（README 只提到 Current 和 LTS 的签名），也没有支持窗口。它们适合核心贡献者测试新补丁，或者极端情况下验证某个 bug 是否已修复。对于任何生产系统，Nightly 都是错误选择。即使你只是想在 CI 中提前发现兼容问题，也应该使用 Current 而非 Nightly，因为 Current 至少经过发布团队的签名和基本测试。
语义化版本与发布签名的约束
Current 和 LTS 版本遵循语义化版本控制。这意味着主版本号变更代表破坏性变更，次版本号代表向后兼容的功能添加，补丁号代表向后兼容的缺陷修复。但这个承诺只对官方发布有效。每个 Current 和 LTS 版本都由发布团队成员签名，签名者列表在 README 的 Release keys 部分。如果你从非官方渠道获取 Node.js 二进制，语义化版本承诺就没有意义，因为你无法验证代码是否被篡改。实际中，很多团队使用 nvm 或 n 这类版本管理器，它们下载的是官方二进制，但验证过程通常被跳过。如果你依赖这些工具，至少应定期检查你使用的版本是否仍在支持窗口内。
治理与协作模式对采用的影响
Node.js 采用开放治理模型，由技术指导委员会（TSC）管理。README 中列出了 TSC 投票成员，包括 Antoine du Hamel、Matteo Collina、Rafael Gonzaga 等。这个治理结构意味着版本决策不是由单一公司控制，而是由多方协商。对于企业采用者，这降低了供应商锁定的风险，但也意味着决策速度可能较慢。TSC 有权限制或阻止反复破坏协作的贡献者，这保证了社区讨论的秩序，但不会直接影响你使用哪个版本。更实际的影响是：你可以通过 GitHub 上的 issue 和 PR 参与决策，或者通过 Working Groups 影响特定领域的发展方向。但这种参与需要时间和承诺，普通用户通常只需要关注发布公告和变更日志。
编辑结论
Node.js 适合绝大多数 JavaScript 服务端与工具链场景，但选型必须基于版本轨道而非最新版本号。生产环境应优先选用偶数主版本的 LTS 线路，例如当前的 v24 'Krypton'，它提供 12 个月 Active LTS 加 18 个月 Maintenance，总计 30 个月支持窗口。追求新 API 的库作者或实验项目可以选用 Current 版本，但需接受每 6 个月一次主版本升级带来的破坏性变更。在采用前，先确认你的依赖是否声明了 engines 字段，并检查 Node.js 官方 API 文档中是否有你依赖的 API 被标记为实验性。对于安全敏感部署，务必按 README 中的 gpgv 与 shasum 流程验证二进制签名，不要跳过这一步。Node.js 的版本号语义化承诺清晰，但它的支持周期只对偶数版本兑现，这是选型时最需要记住的一条边界。
社区笔记