Node.js 26 进入 LTS：升级这件事，别等平台替你决定

NodeSource 在 10 月 6 日的周报里确认了 Node.js 26 进入 LTS，紧接着 10 月 7 日，26.11.0 发布，26.11.1 随后可用。同一份周报里还有一句更值得注意的话：Node.js 20 的支持正在各个平台上继续消失，包括 Vercel 和 GitHub Actions。

LTS 的含义被高估了

很多人把 LTS 理解成「可以一直不动」。它不是这个意思。

LTS 的含义是：这条线会拿到安全修复与关键 bug 修复，持续一段时间。它保证的是你留在这里不会被落下，而不是你留在这里不需要动。

真正的截止线通常不来自 Node 官方，而来自平台：

• 托管平台会先停止提供某个运行时；
• CI 的镜像会先把旧版本删掉；
• 依赖库会先在 engines 字段里抬门槛。

这三件事发生的时候，你仓库里的 package.json 一个字都没改，但构建已经挂了。

一次真实的升级顺序

我这边的顺序大概是这样的：

1. 先在 CI 里加一条新版本的构建，和现有版本并行跑。这一步不改任何依赖，只是看它红不红；
2. 红了就修，修完再合并。这时候线上还是旧版本，风险为零；
3. 确认绿了，再把 engines 和 CI 的主版本切过去；
4. 最后才动本地开发环境。

关键在第 1 步和第 4 步的顺序：先让 CI 用新版本，最后才让本机用新版本。反过来的话，你会在本地遇到一堆问题，但不知道哪些是真问题、哪些是环境差异。

顺带说一下 N|Solid

同一份周报里提到 N|Solid Runtime 6.3.8 支持最新的 Node.js 22 与 24。如果你在用这类带监控的运行时，注意它的支持矩阵往往比 Node 官方慢一拍——升级前先看它的版本表，不然会卡在「Node 升了、监控没跟上」。

另外 NodeConf EU 的回顾已出，JSConf México 排在 10 月 28 到 30 日。

我的判断

我的原则很简单：跟着 LTS 走，但不要等到平台来通知我。

具体做法是把「运行时版本」当成一个有到期日的依赖来管理——它和你的 npm 包一样，会过期，也会在过期时以构建失败的形式提醒你。区别只在于，依赖过期时你通常只有一天时间去处理，而运行时版本你有一年。

这一年不用来升级，最后就会用来救火。