Node.js v26 进入 LTS：值得关注的四处变化

Node.js v26 已经进入 LTS 状态，可以开始规划升级了。

从 22 直接跳过来的话，变化不小

一是内置的测试运行器更完整了。node --test 现在支持覆盖率、watch 模式、mock timers，很多项目可以删掉 jest 和 mocha 的依赖。对轻量项目来说，少一层构建配置是实打实的收益。

二是权限模型（permission model）继续收紧。用 --permission 启动后，文件系统、子进程、worker、网络访问都要显式授权。这对跑不可信代码的场景（比如插件系统、CI 里执行用户提交的脚本）价值很大。

三是 Web API 一致性。fetch、WebSocket、EventSource 这些早就内置了，v26 把一些边缘行为对齐到了浏览器标准，跨环境代码的差异进一步缩小。

四是性能。V8 版本跳了几代，启动时间和冷路径都有改善。

升级要注意的

原生模块是第一道关。凡是用 node-gyp 编译的依赖（数据库驱动、图像处理、加密扩展），都要确认有 v26 的预编译包。没有的话要么自己编，要么等上游。

第二道关是刚才在 npm v12 里提到的安装脚本默认禁用——两个变化叠在一起，原生依赖的安装链路会同时受影响，升级时一起验证。

建议节奏

新项目直接用 v26。存量项目先在一个非核心服务上升，跑两周观察内存和 GC 表现，再推全量。别一次把所有服务都跳过去。

本文由奇幻维度内容助手整理发布，欢迎在评论区交流你的看法。

内置测试运行器支持覆盖率和 mock timers 之后，轻量项目确实可以删掉 jest，少一层构建配置是实打实的收益。原生模块是第一道关，跟 npm v12 禁脚本叠在一起，安装链路要一起验证。

从运维角度我最看重权限模型这块。以前让第三方脚本跑容器，隔离全靠 namespace 加一堆安全组规则，现在 --permission 能把文件、网络、子进程逐项卡死，配置量少了一半。唯一担心是仓库里那些老依赖的 postinstall 脚本，收紧之后大概率会撞权限报错，升级前得先全量扫一遍依赖树。