Node.js 26 LTS登陆Vercel：默认HTTP/2与Temporal API

Vercel 平台宣布 Node.js 26 LTS 已面向构建流程和 Vercel Functions 正式可用（Generally Available）。对于在 Vercel 上运行服务端逻辑的开发者来说，这次升级不只是一次版本号变动，而是把几个能直接影响函数性能与代码写法的底层能力推到了默认位置。

三个值得关注的运行时变化

内置 fetch 默认走 HTTP/2

Node.js 26 中，内置 fetch 所使用的 Undici 升级到 8 版本，并为支持 HTTP/2 的服务器默认启用 HTTP/2。最直接的影响是：多个请求可以复用同一条连接，而不是像 HTTP/1.1 那样容易受连接数限制。

当 Vercel Functions 需要通过 HTTP 访问外部 API 或数据库时，这种连接复用能减少握手与排队开销，官方描述为"可降低延迟"。对高频调用外部服务的函数而言，这是一项无需改代码就能获得的收益。

如果现有服务依赖 HTTP/1.1 的行为（例如某些中间层或调试工具对协议有特殊要求），Vercel 提供了回退开关：在环境中设置 VERCEL_FETCH_DISABLE_H2 为 1 并重新部署，即可保持 HTTP/1.1。

Undici 是 Node.js 官方实现的内置 HTTP 客户端，fetch、WebSocket 等 Web 标准 API 在 Node 中的底层都由它提供。它并非简单封装 http 模块，而是用 C++ 与 JavaScript 混合实现的高性能客户端，支持连接池、keep-alive、代理与 HTTP/2。Undici 的版本与 Node 主线绑定，8 版本对应的关键变化就是为支持 HTTP/2 的服务器默认协商 h2 协议。

HTTP/2 与 HTTP/1.1 的差异不只是“更快”：它把请求切分为帧并在同一 TCP 连接上多路复用，可避免 HTTP/1.1 的队头阻塞；同时支持头部压缩（HPACK）。但这也意味着连接生命周期、超时与错误重试的语义和过去不同，某些中间代理或老版本服务端对 h2 支持不完整时可能暴露出握手失败或连接复用异常，这正是 Vercel 提供回退开关的原因。

Temporal API 进入运行时

Date 对象长期被诟病的问题——可变性、时区处理繁琐、日历支持薄弱——在 Node.js 26 中获得了一个官方替代方案。Temporal API 提供不可变的值类型，并内置时区与日历支持。

对业务代码来说，这意味着日期计算、跨时区展示、夏令时边界处理等场景可以少写不少辅助函数。不过迁移需要成本：Temporal 的 API 形态与 Date 差异较大，已有代码不会自动切换，团队需要评估是否值得逐步替换。

Temporal 是 TC39 提案中的现代化日期时间 API，经过多年标准化后进入正式阶段。它把“时间点”和“墙上时间”严格区分：Temporal.Instant 表示绝对时间轴上的点，Temporal.ZonedDateTime 表示带时区的本地时间，PlainDate、PlainTime 则不带时区。这种类型划分从设计上避免了 Date 把时刻与本地表示混为一谈所导致的常见 bug。

Date 的问题根源在于它是可变的毫秒时间戳包装，月份从 0 开始计数，时区只能通过字符串隐式处理，夏令时的重叠与跳过时段无法表达。Temporal 的所有对象都是不可变的，运算返回新值，并提供显式的时区解析、日历系统（如 iso8601、japanese）以及 Duration 差值类型。迁移时需要注意，Temporal 目前不是全局默认导出可直接替换 Date 的语法糖，而是独立命名空间 Temporal，与现有库（如 date-fns、Luxon）的互操作需逐一评估。

V8 14.6 与 getOrInsert()

底层 JavaScript 引擎升级到 V8 14.6，带来的实用新特性之一是 Map.prototype.getOrInsert()：键存在时返回已有值，不存在时插入默认值。这类"查不到就写入"的模式在过去需要先 get 再判断再 set，现在可以一行完成，代码更紧凑，也减少了重复查找。

Map.prototype.getOrInsert() 是 TC39 的 “Map upsert” 提案落地到 V8 的实现，与之配套的还有 getOrInsertComputed()，后者接受一个回调，仅在键不存在时才计算并插入默认值，适合默认值构造代价较高或依赖其他状态的场景。

相比 if (!map.has(k)) map.set(k, v) 的写法，新方法把查找与插入合并为一次内部操作，在语义上更清晰，也能避免在 has 与 set 之间被其他代码修改映射的竞态问题。需要注意，默认值参数会被立即求值，因此不希望在键已存在时付出构造开销，应改用 getOrInsertComputed()。该特性属于运行时 API，使用前需确认类型定义（如 @types/node 与 TypeScript 的 lib 配置）已同步更新，否则编辑器会报未知方法。

如何在 Vercel 上升级

升级路径分为几种情况，官方给出了明确说明：

• 新项目：Node.js 26 已是所有新项目的默认版本，无需额外配置。
• 自动升级：如果现有项目 package.json 中的 engines.node 字段允许 26（例如写成 >=20），下一次部署时构建就会自动使用 Node.js 26。这类项目需要注意"被动升级"带来的行为差异，尤其是前面提到的 HTTP/2 默认开启。
• 手动升级：将 engines.node 显式设为 26.x 并重新部署，适合希望锁定版本、明确控制升级时机的团队。
• 预构建部署：需要使用 Vercel CLI 65.8.0 或更高版本，才能部署 Node.js 26 的 Functions。

Node.js 26 的次版本与补丁更新会在构建和 Vercel Functions 上自动滚动发布，开发者不需要为每个小版本手动操作。

升级前的几点判断

这次变更的实质是把运行时默认值向前推进了一格。HTTP/2 默认开启属于"静默生效"的改动——代码没变，但网络行为变了。对于依赖外部服务、且这些服务对 HTTP/2 支持参差不齐的项目，建议在升级后观察函数调用的稳定性，必要时用环境变量回退。

Temporal 和 getOrInsert() 则是渐进式收益：它们不会强制你改写代码，但为后续重构提供了更现代的语法基础。把日期逻辑迁移到 Temporal 需要单独排期，不宜与运行时升级捆绑在一起做。

对大多数项目而言，最稳妥的做法是先确认 engines.node 的取值范围，判断自己会走自动升级还是手动升级路径，再决定是否需要为 HTTP/2 相关行为准备回退方案。",