2026-11-07：如何依据 Node.js 官方支持周期规划升级

规划升级时，先确认各环境实际运行的 Node.js 版本，并对照官方支持状态确定紧迫程度；再从仍受支持的 LTS 版本中筛选候选，检查依赖、完成验证并准备回退。官方支持状态是筛选依据，不代表项目已经兼容，也不意味着可以跳过测试。

先核对官方支持状态

根据 2026-11-07 13:59 UTC 读取的 Node.js Release 官方发布表，以下是当时的状态。结束支持日期是计划日期，可能调整；实施升级前应重新核对官方资料。2026-11-07 14:38 UTC 读取的官方计划 JSON 与表中这三条发布线的维护阶段日期和结束日期一致。

Active LTS 接收经发布团队审核、认为适合且稳定的新功能、错误修复和更新。官方对 Maintenance 的这一定义仅适用于 Node.js 26 及以前的发布线：主要接收关键错误修复和安全更新，发布团队也可酌情加入新功能，通常是有助于迁移到较新发布线的功能。

从现有版本确定升级方向

在生产、构建和 CI 等实际执行 Node.js 的环境中分别检查版本，例如在对应环境运行：

node --version

结果只代表执行该命令的环境。还应记录服务使用的系统或容器基础镜像、包管理器、部署方式和负责人，并检查 package.json 的 engines 字段及 CI 配置。需要详细盘点时，可参阅站内相关文章《升级 Node.js 前，如何盘点开发机、CI 和生产环境的版本与安装来源》。

将各环境的主版本与实施时的官方发布表对照：如果已停止维护，应优先安排迁移；如果仍受支持，也要根据剩余支持时间预留依赖适配、测试和发布窗口。生产应用可优先评估仍受支持的 LTS 发布线，再结合项目约束选择目标，而不是仅因版本较新就切换。官方时间表不能保证第三方依赖按同一进度适配。

检查候选版本与项目的兼容性

查看主要框架和依赖的官方兼容性说明及项目锁文件，重点检查原生扩展、构建工具、数据库驱动和容器基础镜像。跨多个 Node.js 主版本升级时，逐项阅读相关版本的官方变更说明，记录需要调整的配置或代码。

特别留意原生插件：官方文档指出，直接使用 Node.js 和 V8 API 的插件可能因 V8 API 在主版本间变化而需要更新或重新编译。这是需要验证的风险，并不表示所有原生模块都不兼容。如果关键依赖尚不支持候选版本，先确认能否升级或替换，再决定是否选择其他仍受支持的目标或调整升级时间。

在接近生产的环境中验证

使用候选 Node.js 版本和项目锁文件，在与生产尽量一致的系统或镜像中安装依赖，运行构建、自动化测试和关键业务流程。检查应用启动、日志、后台任务、数据库连接和资源占用，并确认原生模块在目标环境中能够安装和加载。

依赖安装成功只是起点，不等于应用兼容。若构建、测试或关键流程失败，先定位并修复依赖、代码或配置问题，再重新验证；关键问题未解决时，不应进入正式发布。以上是建议的验证范围，具体通过标准应由项目在发布前确定。

分批发布，并让回退可执行

发布前保留上一版应用制品、运行时镜像和对应配置，明确回退负责人及触发条件，例如错误率持续升高或关键任务无法完成。先向少量实例或流量发布，观察日志、错误率和关键业务指标；达到事先约定的条件后再逐步扩大范围，出现回退条件则停止扩大并执行回退。

提前验证旧版本能否重新部署，并检查数据库迁移、队列消息和缓存格式是否允许旧代码继续运行。对于不可逆变更，应另备数据恢复方案，并确认恢复所需资源可用。如果旧版本已停止维护，回退只能作为短期止损；恢复服务后仍需修复问题并迁移到受支持的版本。

raw.githubusercontent.com

raw.githubusercontent.com

raw.githubusercontent.com

raw.githubusercontent.com