Vite 驱动的 Next.js 应用：Vinext 1.0 发布

当我们在二月 启动 Vinext 时，这是一场大胆的为期一周的 AI 驱动实验的结果，旨在看看一名工程师和一堆令牌能在多大程度上复制由 Vite 支持的 NextJS 框架。

在那次实验之后的七个月里，Vinext 已成长为客户信任并在高流量、动态应用的生产环境中运行的框架。

今天我们宣布发布 Vinext 1.0，这是我们让 Next.js 应用能够在任何地方部署的旅程中的最新一步。Vinext 让你可以将任何 Next.js 应用（无论是为 Pages 还是 App Router 构建的）转换为可移植的形式，部署到任何 Web 平台，包括 Cloudflare Workers 免费计划、Netlify 或 AWS Lambda。

Vinext 1.0 带来了兼容性、稳定性和缓存行为的全面改进，并为项目的长期发展奠定基础。现在正是将你的 Next.js 项目转换为 Vinext 的最佳时机；只需运行 npx vinext check 和 npx vinext init。

升级到 1.0

发布时 Vinext 很有前景，但并不完整。此后，我们花了大量时间改进 App Router 的兼容性，并将其扩展到 Pages Router 应用——我们了解到许多客户长期以来一直是 Pages Router 的忠实粉丝，拥有大型且迁移复杂的应用。我们不想让 Vinext 成为仅适用于使用最新 App Router 功能的人的工具。

我们的重点是同时支持这两种路由器，并密切关注我们的测试兼容性，对于大多数重要的客户需求功能，其兼容率已超过 99%。

这一改进得益于围绕我们 GitHub 项目 的社区。Vinext 一推出，该社区就将其应用于各种应用程序，以发现差距。在他们的审查下，我们发现了一些在测试覆盖范围中不易立即显现的挑战。Vinext 必须完全按 Next.js 的行为运行。仅仅模仿同名函数是不够的。构建一个替代的 import { revalidatePath } 还算简单；难点在于确保它正确影响渲染页面、缓存条目和后续请求。

跟踪请求通过应用程序，确保 Vinext 按预期响应——不仅复制 API，还复制这台机器的行为——无疑是更具挑战性的方面。

一旦我们修复了问题并推出新功能，保持不回退尤为重要，尤其是当 Next.js 做出更改时。这就是我们构建测试套件的原因：数千个聚焦测试覆盖了两种路由器、开发和生产服务器以及 Node.js 和 Cloudflare Workers 的部署目标的核心框架行为。我们还在每晚对 Vinext 运行 Next.js 的端到端测试套件，为我们提供持续的兼容性窗口，并确保我们能立即发现由合并更改引起的回退。除了自动化测试，我们还直接与在生产环境中使用 Vinext 的大型客户合作，确保他们没有遇到问题。

1.0 包含哪些内容

我们从使用 Vinext 的客户那里得到的最清晰的信息是，某些 Next.js 功能已经包含在框架中，Vinext 并不需要做 所有 Next.js 在最近版本中推出的功能，才能对他们极其有用。因此我们专注于在你需要的地方提供更好的支持：

• App Router、Pages Router 与混合应用： 我们听到客户说 Pages Router 仍然重要，迁移不是一步完成的。Vinext 因此支持两种路由路径，包括 React Server Components、Server Actions、API 路由、路由处理器、middleware 和客户端导航。
• 完整的页面生命周期： 页面可以以多种方式渲染：在服务器上、在构建时预渲染、导出为静态资源，或使用页面级 Incremental Static Regeneration (ISR) 缓存。我们已确保后台和按需重新验证与任何输出都兼容。
• 缓存： Vinext 在 App Router、Pages Router 以及支持的运行时之间共享一套缓存函数。我们还支持使用 Cloudflare 的 Workers Cache。
• 可观测性： Vinext 在两种路由中提供兼容 Next.js 的追踪，因此现有的 OpenTelemetry 和 Sentry 设置仍可正常工作。在 Cloudflare Workers 上，追踪还可与原生 Workers Observability 集成。
• Next.js 生态系统兼容性： Vinext 实现了公共 next/* 接口，并支持常见的 Next 模式，用于身份验证、MDX、图像优化、字体、元数据、环境变量等。
• 对 Workers 的一流运行时支持： 虽然 Vinext 可以在任何地方运行，服务器代码可以在开发和生产环境中运行于 Cloudflare workerd 运行时，并直接访问图像优化、hyperdrive 等绑定。

我们还将迁移纳入框架：只需执行两条命令即可验证您的 Next.js 安装及任何修改是否兼容，并在保留所有原有 Next.js 项目结构的同时设置 Vite 和部署配置。

当我们与团队讨论哪些功能对他们重要时，出现了一个突出点。Next.js 16 认为 Cache Components 是框架未来的重要组成部分，但我们谈到的大多数团队并未使用它们，也不认为支持是迁移的前提。因此，Vinext 目前对驱动 Cache Components 的 “use cache” 指令支持有限，虽然我们会继续改进兼容性，但我们更专注于上述核心优先级。

预渲染与缓存预热

当我们首次宣布 Vinext 时，它支持在首次请求后进行 Incremental Static Regeneration (ISR)，但尚未在构建期间渲染页面。应用使用 generateStaticParams() 和 getStaticPaths() 来识别在构建时应渲染的页面，并期望页面级 ISR 将这些初始响应与后台和按需重新验证连接。

Vinext 1.0 支持两种路由的该生命周期。它可以在构建期间预渲染 App Router 和 Pages Router 路由，通过页面级 ISR 提供这些响应，并可按路径或标签失效。它还支持输出：当您想要的结果是完全静态站点时，使用 "export"。

但这让我们产生了疑问：为什么渲染需要在构建期间进行？

拥有数万甚至数十万可能 URL 的网站，可能会在渲染流量很少的页面上耗费大量时间。构建过程无法评估大多数网站所经历的长尾流量，因此无法将计算时间集中在更少但更关键的页面上。相反，你会浪费数小时等待顺序构建逐页完成，已远在最重要路由完成之后。

缓存预热是我们的解决方案，将页面预渲染从构建机器迁移到 Cloudflare 的网络。开发者可以继续使用 Next.js 原语来识别需要预渲染的页面，Vinext 还能额外识别高流量页面并加入此列表。这一过程在你的网站部署到生产环境之前在后台完成，确保一旦上线即可快速从 Cloudflare 缓存提供响应。

在部署过程中，这一步是通过上传新的 Worker 版本并将其部署到 0% 的生产流量，然后专门从该版本请求页面。这样可以在任何真实用户访问新部署之前让渲染管道先行工作。缓存填充完成后，部署即可安全提升。

接下来我们要做的

如果最初的实验创造了单次的 slopfork，后续更重要的部分是我们如何让这一自我改进过程持续无限运行。

该项目现在专注于让框架与上游的所有变更保持同步。Next.js canary 每天都会收到新的提交。每天早上，代理会审查更改，获取差异，并为任何可能影响 Vinext 的事项打开跟踪问题。每晚，我们在对 Vinext 运行 Next.js 测试套件后重新生成兼容性矩阵。

当这些测试或问题之一揭示缺口时，代理现在能够在两个代码库中识别更改，构建重现，迁移任何相关测试，并提出修复方案。

此审查已捕捉到缺失案例、不安全的缓存行为，以及开发与生产服务器之间的差异。

自动化帮助我们将活动流缩小为值得关注的重点变更，使项目维护者仅关注那些需要了解流程如何从 Next.js 实现映射到 Vite 的问题。

我们正在 Cloudflare 建立一个开源软件工厂，你可以在 GitHub 上查看我们的进展。

试一试

Vinext 可用于新的应用程序以及现有的 Next.js 项目。

今天开始一个新应用：

或者迁移现有应用：

然后将其部署到 Cloudflare Workers，并使用我们的缓存预热：

访问 vinext.dev 获取文档、示例和当前兼容性矩阵。Vinext 是开源的，托管在 github.com/cloudflare/vinext。欢迎提交问题、拉取请求、应用重现和反馈。