Node.js 24 进入 LTS：Krypton 管到 2028，升级前先看这几个变化

Node.js 24 于 2025 年 5 月发布，10 月 28 日正式进入 LTS，代号 Krypton，维护期到 2028 年 4 月底。这意味着：从 24 起，你的生产环境有了一个可以用三年的基线。

为什么现在升

Node 18 在 2025 年 4 月结束支持，Node 20 也进入了维护尾声。继续留在老版本，代价不是“少几个新特性”，而是拿不到安全补丁。24 的 LTS 窗口覆盖到 2028 年，对大多数项目来说，这是下一次大迁移之前最省心的选择。

三个真实变化

第一，V8 13.6。 新的 JS 引擎带来一些语言层面的改进，也带来性能曲线的变化。如果你的服务对启动时间敏感，升级后值得重新量一次冷启动。

第二，npm 11。 随 24 一起发布的 npm 主版本更新了依赖解析与安装行为。CI 里如果有 lockfile 相关的奇怪报错，先确认 npm 版本与 lockfile 格式是否匹配。

第三，权限模型稳定。 --permission 从实验走向稳定，可以限制文件系统、子进程、网络访问。对“跑第三方脚本”的场景（比如各种构建插件），这是比容器更轻的一层约束。

另外，require(esm) 默认开启：CommonJS 里可以直接 require 一个 ESM 模块，混合模块的老项目迁移会轻松不少。

已知的坑

24.x 早期版本有一个需要留意的回归：Buffer.allocUnsafe 意外返回了零填充的缓冲区。文档承诺的是“未初始化内存”，零填充会改变依赖这个语义的代码行为（性能上也会有差异）。官方表示会在后续 LTS 版本恢复原行为。升级时建议把 Buffer.allocUnsafe 的使用点过一遍，尤其是热路径。

其他要注意的：原生模块需要按新的 ABI 重新编译；Docker 基础镜像记得换到 node:24 系列；CI 的缓存键里最好带上 Node 版本，避免旧缓存串味。

升级顺序

1. 本地与 CI 先切 24，跑完整测试；
2. 观察一周的启动时间、内存与事件循环延迟；
3. 再动生产，按灰度分批；
4. 最后清理那些只在老版本上成立的兼容代码。

一句判断

Node 24 的升级价值不在新语法，而在把安全补丁的窗口重新打开。LTS 是三年期的承诺，越早切换，后面越从容。

封面图：Node.js 官方标识（Wikimedia Commons）。