Cloudflare 发布 vinext：AI 一周重构 Next.js 框架，Vite 驱动、一键部署

上周，Cloudflare 的一名工程师完成了一项看似不可能的任务：他指导 AI 模型，从零开始重新实现了当前最流行的 Next.js 框架。成果是一个名为 vinext（读作“vee-next”）的项目，它可以作为 Next.js 的即插即用替代方案。它基于 Vite 构建，并且只需一条命令就能将应用部署到 Cloudflare Workers。初步基准测试显示，在生产环境构建中，速度最高提升了 4 倍，客户端打包体积最高减小了 57%。目前已有客户在生产环境中正式使用。

整个项目的核心开发时间不到一周，AI API 调用（Token）的总成本大约为 1100 美元。

Next.js 的部署难题

作为最流行的 React 框架，Next.js 拥有数百万开发者用户，支撑着互联网上数量庞大的生产环境应用。它提供了一流的开发者体验，这无疑是其成功的关键。

然而，当开发者尝试将 Next.js 应用部署到更广泛的无服务器生态时，问题就出现了。Next.js 的工具链高度定制化：虽然它在 Turbopack 上投入了大量资源，但如果要部署到 Cloudflare、Netlify 或 AWS Lambda 等平台，仍然需要对 Next.js 的构建输出进行改造，以适配目标平台的运行时环境。

你可能会想到 OpenNext 这个解决方案。确实，OpenNext 的核心目标就是解决这个问题，包括 Cloudflare 在内的多家厂商都为其投入了工程资源。它虽然能工作，但很快就会遇到各种限制，变成一场“打地鼠”式的修复游戏。逆向工程 Next.js 的构建输出被证明是一种困难且脆弱的方案，版本间的不可预测变更需要大量的修正工作。

Next.js 官方也在开发一等适配器 API，但目前仍处于早期阶段。即便有了适配器，构建过程依然高度依赖定制的 Turbopack 工具链。此外，适配器主要覆盖构建和部署环节。在开发阶段，next dev 完全在 Node.js 中运行，无法接入其他运行时。这意味着如果你的应用使用了平台特定的 API（如 Cloudflare 的 Durable Objects、KV 或 AI 绑定），除非采用变通方案，否则你无法在开发环境中直接测试这些代码。

vinext 是什么？

如果换一种思路，不是去适配 Next.js 的输出，而是基于 Vite 直接重新实现 Next.js 的 API，结果会怎样？Vite 是支撑 Astro、SvelteKit、Nuxt、Remix 等大多数其他前端框架的构建工具。这是一次干净的重新实现，而不是一个封装或适配层。说实话，起初我们并不认为这能成功。但现在已经是 2026 年，软件构建的成本已经发生了根本性的改变。

我们取得的进展远超预期。

npm install vinext

只需将你脚本中的 next 替换为 vinext，其余一切保持不变即可。你现有的 app/、pages/ 目录和 next.config.js 无需修改就能正常工作。

vinext dev          # 启动带热重载的开发服务器
vinext build        # 执行生产构建
vinext deploy       # 构建并部署到 Cloudflare Workers

这不是一个基于 Next.js 和 Turbopack 输出的封装层，而是对 Next.js API 的完整替代实现：路由、服务端渲染（SSR）、React Server Components（RSC）、服务端操作（Server Actions）、缓存、中间件——所有功能都基于 Vite 构建，并以 Vite 插件的形式实现。最重要的是，得益于 Vite Environment API，Vite 的构建输出可以在任何平台上运行。

数据表现如何？

初步的基准测试结果令人振奋。我们使用一个包含 33 条路由的共享 App Router 应用，对比了 vinext 和 Next.js 16 的表现。两个框架执行相同的工作：编译、打包并为服务端渲染路由做准备。我们在 Next.js 构建中禁用了 TypeScript 类型检查和 ESLint（以匹配 Vite 在构建期间不运行这些检查的行为），并使用 force-dynamic 防止 Next.js 花费额外时间去预渲染静态路由。测试的目标是仅测量打包器和编译器的速度。

生产构建时间对比：

客户端打包体积（Gzip 压缩后）对比：

需要明确的是，这些基准测试测量的是编译与打包速度，而非生产环境下的运行性能。测试样本是单一应用，并非所有生产应用的代表。我们预计随着项目的迭代，数据会发生变化。完整的测试方法与历史结果均已公开，应作为方向性参考，而非绝对结论。

不过，这一方向已经展现出积极信号。Vite 的架构，尤其是即将在 Vite 8 中推出的、基于 Rust 的打包器 Rolldown，在构建性能上具备结构性优势，这一点在测试中体现得很明显。

一键部署到 Cloudflare Workers

vinext 将 Cloudflare Workers 作为首要部署目标进行构建。只需一条命令，就能从源码直接部署为一个可运行的 Worker：

vinext deploy

这条命令会处理所有环节：构建应用、自动生成 Worker 配置并完成部署。App Router 和 Pages Router 都可以在 Workers 上运行，支持完整的客户端水合（hydration）、交互式组件、客户端路由导航与 React 状态。

在生产缓存方面，vinext 内置了开箱即用的 Cloudflare KV 缓存处理器，支持增量静态再生（ISR）：

import { KVCacheHandler } from "vinext/cloudflare";
import { setCacheHandler } from "next/cache";

setCacheHandler(new KVCacheHandler(env.MY_KV_NAMESPACE));

KV 是大多数应用的默认选择，但缓存层是可插拔的。你可以通过 setCacheHandler 替换为任何合适的后端。我们也在优化 Cache API，目标是保持灵活性，让你选择最适合自己应用的缓存策略。

实时运行示例：

• App Router Playground
• Hacker News 克隆版
• App Router 最小示例
• Pages Router 最小示例

我们还有一个展示 Cloudflare Agents 在 Next.js 应用中实时运行的示例。由于整个应用在开发和生产阶段都运行在 workerd 中，因此无需使用 getPlatformProxy 这类变通方案，可以无妥协地使用 Durable Objects、AI 绑定等所有 Cloudflare 专属服务。

框架开发是团队协作

目前，vinext 的首要部署目标是 Cloudflare Workers，但这只是冰山一角。项目中约 95% 的代码都是纯 Vite 生态相关的内容：路由、模块垫片（shim）、SSR 流程、RSC 集成——这些都不是 Cloudflare 特有的。

Cloudflare 希望与其他托管服务商合作，让他们的客户也能使用这套工具链。实际上，我们在不到 30 分钟内就在 Vercel 上完成了概念验证。这是一个开源项目，为了长期发展，与整个生态伙伴合作、确保能够持续投入至关重要。我们欢迎来自其他平台的贡献（PR）。如果你有兴趣为 vinext 新增部署目标，欢迎提交 Issue 或联系我们。

当前状态：实验阶段

必须明确指出：vinext 目前仍处于实验阶段。它诞生还不到一周，尚未经过大规模真实流量的实战检验。如果你考虑将其用于生产环境，请务必谨慎评估。

尽管如此，我们的测试套件已相当完备：包含超过 1700 个 Vitest 测试和 380 个 Playwright 端到端测试，其中部分测试直接移植自 Next.js 官方测试套件以及 OpenNext 的 Cloudflare 一致性测试套件。我们已通过 Next.js App Router Playground 完成验证，对 Next.js 16 API 的覆盖率达到 94%。

来自真实用户的早期反馈同样鼓舞人心。例如，National Design Studio 团队已在其测试站点 CIO.gov 上运行 vinext，并将其用于生产环境，构建时间与打包体积均得到显著优化。README 中已如实列出了目前不支持的功能与已知限制。

关于预渲染

vinext 已开箱即用支持增量静态再生（ISR）。与 Next.js 一样，任何页面在首次请求后都会被缓存，并在后台重新验证。

目前，vinext 尚不支持构建时的静态预渲染。在 Next.js 中，没有动态数据的页面会在 next build 阶段被渲染并作为静态 HTML 提供；对于动态路由，可以通过 generateStaticParams() 枚举需要预构建的页面。vinext 暂不支持此功能，但这已在路线图上。如果你的网站是 100% 预构建的静态 HTML，使用 vinext 目前可能不会带来太多收益。对于纯静态内容，或许迁移到专为此设计的、基于 Vite 的框架（如 Astro）会是更好的选择。

不过，对于并非纯静态的网站，我们有信心能做得比在构建时预渲染所有内容更好。

流量感知预渲染

Next.js 会在构建期间预渲染 generateStaticParams() 中列出的每一个页面。一个拥有 10000 个产品页面的网站，意味着构建时要执行 10000 次渲染，即使其中 99% 的页面可能永远不会被访问。构建时间会随着页面数量线性增长，这也是大型 Next.js 网站构建耗时可能长达 30 分钟的原因。

为此，我们构建了 流量感知预渲染。该功能目前仍处于实验阶段，我们计划在经过更多验证后将其设为默认模式。

理念很简单：Cloudflare 本身就是网站的反向代理，我们掌握着流量数据，清楚哪些页面被实际访问。因此，vinext 既不会预渲染所有内容，也不会完全不预渲染，而是在部署时查询 Cloudflare 的区域分析数据，只预渲染那些关键页面。

vinext deploy --experimental-tpr
  Building...
  Build complete (4.2s)
  TPR (experimental): Analyzing traffic for my-store.com (last 24h)
  TPR: 12,847 unique paths — 184 pages cover 90% of traffic
  TPR: Pre-rendering 184 pages...
  TPR: Pre-rendered 184 pages in 8.3s → KV cache
  Deploying to Cloudflare Workers...

对于一个拥有 10 万个产品页面的网站，幂律分布通常表明：90% 的流量只集中在 50 至 200 个页面上。这些页面可以在几秒钟内完成预渲染，其余内容则回退到按需 SSR，并在首次请求后通过 ISR 缓存。每次新部署都会根据当前的流量模式刷新预渲染的页面集合，无需依赖 generateStaticParams()，也无需将构建过程与生产数据库绑定。

直面挑战：这一次用上了AI

这类项目通常需要一支工程师团队耗费数月乃至数年才能完成。此前，Cloudflare 和其他团队都曾尝试过，但涉及的范围实在太广：两套路由、33 个以上的模块垫片、服务端渲染管道、RSC 流式传输、文件系统路由、中间件、缓存、静态导出……难怪一直没人能真正做成。

而这一次，我们仅用不到一周就完成了——由一名工程经理指导 AI 完成。

首次提交始于 2 月 13 日。当晚，Pages Router 与 App Router 就已实现基础 SSR、中间件、服务端操作与流式传输。次日下午，App Router Playground 已能渲染 11 条路由中的 10 条。第三天，vinext deploy 已可将应用部署到 Cloudflare Workers，并支持完整的客户端激活。剩下的时间则用于稳定性加固：修复边界场景、扩充测试套件、将 API 覆盖率提升至 94%。

与早期尝试相比，究竟是什么发生了改变？答案是，AI 已经变得足够强大。

为什么这个问题适合用 AI 解决？

并非所有项目都能如此顺利。这个项目之所以成功，是因为几个关键因素在恰当的时机形成了合力：

1. Next.js 定义清晰：它拥有详尽的文档、庞大的用户群和多年积累的训练数据（教程、问答）。当要求 AI 实现 getServerSideProps 或解释 useRouter 时，它很少出现“幻觉”，因为它完全了解 Next.js 的机制。
2. Next.js 拥有完备的测试套件：其代码仓库中包含数千个覆盖所有功能和边界场景的端到端测试。我们移植了其中许多测试，这为我们提供了可机械验证的“规范”。
3. Vite 是优秀的基础：它解决了前端工具链的核心难题（HMR、原生 ESM、插件 API）。我们无需从头开发打包器，只需让 Vite 适配 Next.js 的 API。@vitejs/plugin-rsc 插件也为实现 RSC 提供了基础。
4. 模型能力终于跟上：就在几个月前，这还被认为是不可能的。新一代模型能够理解完整架构、推理模块间交互，并能稳定生成正确代码以维持开发节奏。它们有时能深入 Next.js、Vite 和 React 的内部机制去定位问题。

所有这些条件必须同时具备：目标 API 文档完善、测试套件全面、底层构建工具坚实，再加上能够处理复杂逻辑的模型。缺少任何一环，效果都会大打折扣。

我们是如何实现的？

vinext 几乎每一行代码都由 AI 编写，但质量标准与人工编写代码相同。项目拥有 1700+ 个 Vitest 测试、380 个 Playwright E2E 测试，通过了严格的 TypeScript 和代码规范检查。建立完善的质量保障机制是让 AI 高效发挥作用的关键。

整个过程始于一份详细规划。在明确了架构、顺序和抽象层后，工作流程变得清晰：

1. 定义任务（例如：“实现 next/navigation 垫片，包含 usePathname、useSearchParams、useRouter”）。
2. 让 AI 编写实现代码与测试用例。
3. 运行测试套件。
4. 如果测试通过就合并；如果不通过，则将错误信息交给 AI 进行迭代修复。
5. 重复这一过程。

我们还为代码审查设置了 AI 智能体。PR 提交后，一个智能体会自动审查；审查意见返回后，另一个智能体会处理这些意见。对于浏览器级别的测试，我们使用 agent-browser 来验证实际渲染输出、客户端导航与水合行为。

整个项目期间，我们运行了 800 多个 AI 编码会话，总成本约为 1100 美元。

这对软件意味着什么？

这个项目促使我们思考：为什么技术栈会有这么多层？软件中的大多数抽象实际上是为了辅助人类开发者管理复杂度。我们无法在脑中容纳整个系统，因此通过构建层次来简化工作。

但 AI 没有这样的限制。它可以在其上下文窗口中容纳整个系统，并直接编写代码。它不需要借助中间框架来维持结构，只需要一份规范和一个构建基础。

目前尚不清楚哪些抽象是真正基础的，哪些只是人类认知的“拐杖”。这条界限在未来几年将会大幅改变。vinext 就是一个例证：我们只提供了一份 API 契约（Next.js）、一个构建工具（Vite）和一个 AI 模型，剩下的中间层全部由 AI 编写。我们相信这种模式会在大量软件项目中复现。

如何尝试？

vinext 包含一个用于处理迁移的 AI Agent Skill。它适用于 Claude Code、OpenCode、Cursor 等主流 AI 编码工具。安装后，打开你的 Next.js 项目，让 AI 进行迁移：

npx skills add cloudflare/vinext

然后在你的 AI 编码工具中，打开 Next.js 项目并输入：

migrate this project to vinext

这个 Skill 会处理兼容性检查、依赖安装、配置生成与开发服务器启动，并标记出所有可能需要手动处理的部分。

当然，你也可以手动操作：

npx vinext init    # 迁移现有的 Next.js 项目
npx vinext dev     # 启动开发服务器
npx vinext deploy  # 部署到 Cloudflare Workers

源代码位于 github.com/cloudflare/vinext，欢迎提交 Issue、PR 与反馈。

原文链接： https://blog.cloudflare.com/vinext/