Cloudflare Vinext：一个工程师+AI，一周重写Next.js

8180颗星，一个工程师，七天，一千一百美元

这不是一个创业故事的开头，这是一个开源项目的真实履历。

2026年2月，Cloudflare发布了vinext——一个用Vite重新实现Next.js API表面的插件。发布当天即引爆开发者社区，GitHub星数迅速突破8180。但真正让所有人震惊的不是技术本身，而是它的诞生方式：一个工程师，加上一个AI模型，七天时间，总计花费约1100美元的API Token，就重写了世界上最流行的React框架。

想一想：Next.js是Vercel投入数年、数十名工程师维护的项目，光Turbopack编译器就耗费了海量工程资源。而Cloudflare用一个工程师加AI，把这件事做了一遍。这不是魔法，但比魔法更值得深究——因为它揭示了一套全新的软件开发范式正在浮出水面。

当你以为Next.js生态已经铁板一块时，vinext用最直接的方式告诉你：框架的护城河，可能没有想象中那么深。

vinext到底是什么：不是适配器，是重新实现

理解vinext的关键，在于理解它「不是什么」。

vinext不是Next.js的分支（fork）。它没有复制Next.js的代码，没有继承Turbopack的构建工具链，更没有沿用Next.js的内部架构。它做的事情更加彻底——把Next.js的公开API（路由、服务端渲染、`next/*`模块导入、CLI命令等）当作一份「接口规范」，然后用Vite从头实现了一遍。

打个比方：Next.js是一栋用定制砖块盖的房子。你把它部署到Cloudflare Workers、Netlify或AWS Lambda上，之前只能靠OpenNext之类的工具去拆解、搬运、重新拼装那些砖块——这过程脆弱且充满版本兼容性噩梦。而vinext的做法是：重新烧制一套标准砖块，但让房子的外观和居住体验几乎完全一致。

具体来说，vinext是一个Vite插件，它重新实现了以下Next.js的核心功能：

– App Router和Pages Router：两个路由系统都支持，服务端渲染、流式输出、嵌套布局一应俱全

– 33个`next/*`模块shim：覆盖`next/link`、`next/image`、`next/navigation`、`next/headers`、`next/server`、`next/og`等全部常用导入，无需修改import路径

– React Server Components完整管线：RSC渲染、Server Actions、缓存策略——这些App Router的核心机制全部重新实现

– CLI兼容：`vinext dev`、`vinext build`、`vinext start`，无缝替换原生的`next`命令

一句命令完成迁移：

npx vinext init

你的`app/`、`pages/`目录、`next.config.js`都保持不变。脚本里把`next`换成`vinext`，背后的构建引擎就从Turbopack变成了Vite。

这还不是全部。vinext的测试覆盖达到94%的Next.js 16 API表面，包含1700+个Vitest单元测试和380个Playwright端到端测试。对于一个诞生仅一周的项目来说，这份工程纪律甚至比许多商业产品更严格。

数字不会说谎：4.4倍构建速度，57%更小的客户端包

Cloudflare官方给出了一个33条路由的App Router应用的对比基准测试。关闭TypeScript类型检查和ESLint，采用`force-dynamic`模式避免静态预渲染——纯粹对比打包器和编译器的速度。

结果令人咋舌：

生产构建时间：

– Next.js 16.1.6（Turbopack）：7.38秒

– vinext（Vite 7 + Rollup）：4.64秒，提速1.6倍

– vinext（Vite 8 + Rolldown）：1.67秒，提速4.4倍

客户端Bundle大小（gzip压缩后）：

– Next.js 16.1.6：168.9 KB

– vinext（Rollup）：74.0 KB，减小56%

– vinext（Rolldown）：72.9 KB，减小57%

构建快4倍，打包小一半。这个差距足以让任何在乎CI/CD流水线时间、在乎用户首屏加载速度的团队无法忽视。

不过也要说清楚：这些基准测试衡量的是编译和打包速度，不是端到端用户服务性能。vinext目前更依赖运行时渲染+缓存策略，而Next.js在构建阶段做更多静态预渲染。如果你的应用重度依赖构建时的静态生成（SSG），vinext暂时还不支持——这项功能已在路线图上。但如果你用`force-dynamic`模式，或本身就是服务端渲染为主的应用，vinext的即时回报是肉眼可见的。

更有趣的是部署。vinext的第一部署目标是Cloudflare Workers，一行命令：

vinext deploy

构建、生成Worker配置、上传部署一气呵成。如果你需要部署到其他平台（Vercel、Netlify、AWS、Deno Deploy等），vinext通过集成Nitro来实现多平台输出——设置一个环境变量`NITRO_PRESET`，就能打出对应平台的构建产物。

这意味着什么？你用Next.js写的应用，突然有了「部署自由」——不再被锁定在Vercel的生态里，也不需要通过脆弱的适配器去逆向工程构建产物。

AI写了一个框架，但这不是「AI Slop」

这个故事最容易被误读的部分，是「AI写了一整个框架」。

实际上，Cloudflare的工程师采用了极严格的AI辅助流程：先由人类规划架构，然后将每个模块拆分为明确任务——「实现这个路由匹配逻辑，附带测试」——交给AI模型生成代码。生成后立即运行全部测试套件，失败则迭代修正，直到通过。AI还被集成到代码审查和Playwright浏览器级测试中，捕捉单元测试发现不了的回归问题。整个过程跑过了超过800次OpenCode会话。

关键不是AI有多聪明，而是Next.js有一套成熟的、可测试的公开规范，Vite提供了稳定的基础设施，而人类工程师始终在关键节点做出判断：「这个输出看起来对，但实际上是错的。」

这恰恰是「AI辅助开发」的正确姿势：AI负责生成和迭代，人类负责架构决策和质量把关。那些嘲笑「AI Slop」的人可能忽略了一点——vinext的测试覆盖和质量门禁，比许多纯人类维护的项目都要严格。

当然，vinext目前仍然是实验项目。Cloudflare官方措辞非常克制：「没有经过大规模生产环境的实战考验，谨慎使用。」已知的局限性包括：

– 不支持构建时的静态预渲染（SSG），这在路线图上

– 生产环境的Node.js服务器路径不如Cloudflare Workers路径成熟

– 构建时图片优化功能尚未实现

– Google Fonts从CDN加载，而非像`next/font`那样自托管优化

但即便如此，美国联邦政府网站CIO.gov已经跑在了vinext上，由National Design Studio部署到生产环境。这无疑是最硬核的「生产验证」。

这不止是一个工具，这是一种策略

如果把vinext看作一个单纯的「Next.js替代品」，就低估了Cloudflare的战略意图。

过去几年，前端框架的竞争本质上是一场「部署锁定」的博弈。Next.js好用，但它的最佳部署平台是Vercel；Nuxt好用，但最顺滑的部署路径指向NuxtHub/Netlify。框架和平台之间的绑定，已经成了事实上的行业惯例。

vinext打破了这个惯例。它证明了一件事：Next.js的开发者体验（路由约定、文件结构、模块API）可以被提炼为一份公开接口规范，而这份规范可以在完全不同的工具链上实现。 这意味着「选择Next.js」和「选择Vercel」从技术上是可分离的两个决策。

更深一层的信号是：Vite正在成为前端构建的事实标准。 vinext里大约95%的代码是纯Vite层面的实现——路由、模块shim、SSR管线、RSC集成——没有一处是Cloudflare特有的。这说明Vite生态的成熟度已经足以承载Next.js级别的复杂框架需求。

对开发者来说，vinext的意义是多重的：

– 如果你被困在Vercel的定价模型或平台限制里，vinext提供了一条干净的迁移路径

– 如果你需要利用Cloudflare Workers的全球边缘网络、Durable Objects、KV存储等能力，vinext让你可以继续使用Next.js的开发范式

– 即使你不打算切换框架，vinext的基准测试也向Next.js团队施加了压力——4.4倍的构建速度差距，不可能被无限期忽视

GitHub上8180颗星的数字本身也说明问题：开发者对「框架可移植性」的渴望，远比平台方愿意承认的强烈。

vinext未必会成为Next.js的终结者——它甚至现在还不建议在生产环境大规模使用。但它已经完成了最重要的一件事：在Next.js生态看似无懈可击的围墙上，凿开了一道裂缝。 当框架不再是铁板一块，当部署平台不再是单选题，真正的赢家只有一个——开发者。

这道裂缝会如何扩大，值得我们持续关注。

— END —
LC 智趣厅 · 科技与生活的交点
ihygg.cn