跳到主要内容

Next.js 14、15、16 更新对比

如果只看最近三代，脉络会很清楚：

  • 14：把 App Router 相关能力推到“可以大规模采用”的位置
  • 15：开始重写默认行为，尤其是请求时 API 和缓存语义
  • 16：把 Turbopack、缓存模型、代理边界进一步默认化

一张表先看差异​

维度Next.js 14Next.js 15Next.js 16
核心气质App Router 体系可落地默认行为重写新主线默认化
路由与渲染App Router、Server Actions 稳定、PPR 预览延续 App Router，但更强调请求时语义导航和预取模型继续优化
缓存仍带较多旧默认值fetch、GET Route Handlers、客户端导航默认不缓存cacheComponents、updateTag、refresh、cacheLife 等更完整
构建链Turbopack 大幅推进Turbopack 开发态稳定next dev / next build 默认 Turbopack
网络边界middleware 仍是主叫法middleware 继续使用proxy.ts 成为新的主命名
React 对齐React 18 主线React 19 支持React Compiler 支持稳定
升级风险中等，主要是新旧路由并存较高，默认语义变化明显较高，工具链和配置边界继续变化

Next.js 14：从理念走向可用​

14 的重点主要有三块：

  • Server Actions 稳定
  • Partial Prerendering 预览
  • Turbopack 能力继续前进

这一版的实际意义​

13 把新架构提出来，14 才让很多团队开始认真考虑落地。尤其 Server Actions 稳定之后，表单、写操作、缓存重验证这套链路终于更像完整方案了。

适合怎么判断​

如果项目仍然在 Pages Router 时代，但开始想试 App Router，14 是一个比较自然的过渡点。

Next.js 15：从新能力扩展转向默认行为调整​

15 真正麻烦的地方，不是功能多，而是“以前默认能工作的地方，现在默认行为不同了”。

1. Async Request APIs​

这些请求时 API 开始进入异步模型：

  • cookies()
  • headers()
  • draftMode()
  • params
  • searchParams
import { headers } from 'next/headers';

export default async function Page() {
  const requestHeaders = await headers();
  const userAgent = requestHeaders.get('user-agent');

  return <div>{userAgent}</div>;
}

2. 缓存默认值变化​

官方说明里明确提到，以下场景不再默认缓存：

  • fetch 请求
  • GET Route Handlers
  • client navigations

这会直接影响：

  • 请求次数
  • 页面实时性
  • 开发时对“静态页面”的判断
  • 老项目升级后的体感差异

3. next/form、instrumentation.ts、after()​

15 还补了几块很实用的能力：

  • next/form：让表单提交和导航更顺地接在一起
  • instrumentation.ts：统一服务端监控接入点
  • after()：把非关键副作用放到响应结束后执行

Next.js 16：从“支持新路线”到“默认走新路线”​

16 的感觉很像正式宣告：前面几年铺的路，现在开始默认启用。

1. Turbopack 默认化​

next dev 和 next build 默认都走 Turbopack。

这意味着：

  • 脚本里通常不再需要 --turbopack
  • 如果项目还依赖自定义 webpack 配置，需要单独处理
  • 构建链已经不再把 webpack 视为唯一主线

2. middleware 迁移到 proxy​

这不是简单改名。官方想强调的是：这一层更像“网络边界和路由拦截点”，而不是一个什么都能塞的通用中间件层。

同时升级文档也明确写了：

  • proxy 的 runtime 是 nodejs
  • edge runtime 不支持 proxy
  • 如果仍然依赖 Edge，需要暂时保留 middleware

3. 缓存 API 更成熟​

16 的缓存相关变化比表面看起来更重要。

除了 cacheComponents，还包括：

  • revalidateTag(tag, profile)
  • updateTag(tag)
  • refresh()
  • cacheLife
  • cacheTag

这意味着数据一致性不再只能靠“大范围刷新”，而是可以开始用更细粒度的缓存标签去组织。

4. 路由预取和导航机制继续优化​

官方在升级文档里明确提到两件事：

  • shared layout 只下载一次
  • prefetch 改成更增量的方式

实际观察网络面板时，可能会看到更多细碎请求，但总传输量和重复下载会下降。

三个版本怎么选阅读重点​

如果当前还停留在 14​

最值得优先关注：

  • 15 的 Async Request APIs
  • 15 的缓存默认值变化
  • 16 的 Turbopack 默认化
  • 16 的 proxy.ts

如果已经在 15​

最值得关注：

  • 16 的构建默认值变化
  • 16 的缓存 API 收口
  • 16 对运行时和配置边界的进一步限制

如果现在准备新开项目​

主线认知可以直接按 16 理解：

  • App Router
  • Turbopack
  • Async Request APIs
  • 明确的缓存标签体系
  • proxy 作为网络边界

最容易低估的变化​

1. 不是只有 API 在变，默认语义也在变​

14 到 16 最大的迁移成本，很多时候并不来自语法，而是来自默认行为改变。

2. 缓存已经成为核心心智，不再只是优化项​

旧版里缓存更像加分项；到了 15 / 16，缓存已经直接影响：

  • 页面实时性
  • 请求数量
  • 交互一致性
  • 用户是否立刻看到写入结果

3. 构建链也成了升级风险的一部分​

过去升级 Next，常常主要关心业务代码。现在还要看：

  • 构建脚本
  • 自定义 webpack 配置
  • lint 命令
  • 运行时环境版本

参考资料​