由 Vite 驱动的 Next.js 应用：推出 Vinext 1.0
当我们在二月份推出 Vinext时，它源于一场大胆的、为期一周的 AI 驱动实验，旨在探索一位工程师加上一堆 token 究竟能走多远，去复刻由 Vite 支持的 NextJS 框架。
在那次实验之后的七个月里，Vinext 已经成长为一个我们的客户信赖并用于生产环境、承载高流量动态应用的框架。
今天我们宣布 Vinext 1.0 的发布，这是我们让 Next.js 应用可以在任何地方部署这一旅程中的最新一步。Vinext 让你能够将任何 Next.js 应用——无论它是为 Pages Router 还是 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 路由、路由处理器、中间件和客户端导航。完整的页面生命周期：页面可以通过多种方式渲染：在服务器上渲染、在构建时预渲染、导出为静态资源，或通过页面级增量静态再生成（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 安装以及你所做的任何修改是否兼容，并设置 Vite 和部署配置，同时保留你之前所有的 Next.js 项目结构。
当我们与团队讨论哪些功能对他们重要时，有一点很突出。Next.js 16 表明 Cache Components 是框架未来的重要组成部分，但我们交谈过的大多数团队并未使用它们，也不认为支持它们是迁移的前提条件。因此，Vinext 目前对驱动 Cache Components 的“use cache”指令支持有限，尽管我们会继续改进这方面的兼容性，但我们更专注于上述核心优先事项。
预渲染和缓存预热
当我们首次发布 Vinext 时，它支持在首次请求后进行增量静态再生（ISR），但尚未在构建期间渲染页面。应用程序使用 generateStaticParams() 和 getStaticPaths() 来标识应在构建时渲染的页面，并期望页面级 ISR 将这些初始响应与后台和按需重新验证连接起来。
Vinext 1.0 为两种路由器都支持该生命周期。它可以在构建期间预渲染 App Router 和 Pages Router 路由，通过页面级 ISR 提供这些响应，并按路径或标签使其失效。当您想要的结果是完全静态站点时，它还支持 output: "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 项目。
立即启动一个新应用程序：
npm create vinext-app@latest my-app
或迁移现有应用：
npx vinext check && npx vinext init
然后将其部署到 Cloudflare Workers，并使用我们的缓存预热功能：
npx @vinext/cloudflare deploy --warm-cache
访问 vinext.dev 获取文档、示例以及当前的兼容性矩阵。Vinext 是开源的，地址为
. 欢迎提交 issue、pull request、应用复现以及反馈。
github.com/cloudflare/vinext