一个工程师一周复刻Next.js，七个月后跑进生产环境

一个工程师，一周时间，一堆token。这是Vinext项目最初的起点——一个AI驱动的实验，目标是看看能把Next.js框架在Vite上复刻到什么程度。

七个月后，这个实验变成了客户在生产环境中运行高流量动态应用的框架。Vinext 1.0正式发布。

它的核心能力是：把任何Next.js应用——无论基于Pages Router还是App Router——变成可移植的，能部署到任何Web平台，包括Cloudflare Workers免费计划、Netlify和AWS Lambda。

从实验到生产：兼容性怎么补上的

发布之初的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和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()来识别应该被渲染的页面。