OpenNext 不使用 Next.js 提供的默认路由。相反，它使用自己的路由系统。

历史上，OpenNext 使用与 Next.js 相同的路由系统。但在 Next 13.4.13 中，他们将路由系统移出了 NextServer，并将应用的每个主要部分（即 app router、page router 和 routing）分离到 jest workers 中。这导致了严重的冷启动问题（默认的 create next-app 应用约为 8 秒），使得无法在 lambda 中提供 ISR/SSG 页面。从那以后，OpenNext 一直为使用 Next 13.4.13 或更高版本的每个应用使用自己的路由系统。供参考，Vercel 在 NextServer 内部使用了一个未文档化的 minimalMode 来绕过路由和缓存系统，以便在其基础设施中完成，而不是在 lambda 中。

这一举措还允许 OpenNext 拥有更灵活的路由系统。使用 OpenNext，你可以将路由层放在服务器前面的函数（lambda@edge 或 cloudflare workers）中。你甚至可以直接从路由层提供 ISR/SSG。

以下是 OpenNext 路由系统处理的功能列表：

• 来自 next.config.js（其余部分由 NextServer 本身处理）：
  • Headers
  • Redirects
  • Rewrites
  • basePath
  • i18n
• 中间件
• 可选缓存拦截（即直接从路由层提供 ISR/SSG）
• 在某些情况下处理 404（即当页面不对应任何正则路由时）

Next 中间件

OpenNext 中的 Next 中间件运行方式与 Next.js 中不同。在 Next.js 中，中间件在 NextServer 内部的模拟边缘运行时中运行。在 OpenNext 中，我们修改中间件并将其完全在路由层内运行。因此，如果你在 Node 中运行路由层，你可以在中间件中使用 Node API（这有点棘手，因为它不适用于 next dev，并且涉及一些变通方法，因为 Next 会在捆绑期间移除 Node API。一些示例 在此）。

在最新的 Next 15（也适用于最新的 OpenNext）上，你现在可以在 next.config.ts 中添加一个 experimental 设置，以启用 nodejs 作为中间件的运行时：

const nextConfig: NextConfig = {
  experimental: {
    nodeMiddleware: true,
  },
};
// 然后在你的 `middleware.ts` 中写入：
export const config = {
  runtime: "nodejs",
};

这是在 Next 中引入此功能的 PR (opens in a new tab)。