Vike：Next.js 与 Nuxt 的替代方案
如果你已经厌倦了 Next.js —— 无论是 App Router 的复杂性、Vercel 的平台锁定，还是框架替你做了过多决策 —— 你并不孤单。开发者们正在积极寻找能够提供 SSR 和基于文件的路由，同时又没有那么多负担的 Next.js 替代方案。Vike 是值得认真评估的最成熟选项之一。
本文将介绍 Vike 是什么、它在架构上与 Next.js 和 Nuxt 有何不同，以及在什么情况下它确实是更好的选择。
核心要点
- Vike 是一个基于 Vite 的元框架，提供 SSR、SSG 和 SPA 模式，且不会将你锁定在特定的 UI 库、后端或部署目标中。
- 与 Next.js 和 Nuxt 不同，Vike 是可组合的：你可以自由选择渲染库（React、Vue、Solid）、数据层和服务器。
- 通过
+config.js实现按页面级别的渲染控制，让你可以在同一个项目中混用 SSR、SSG 和 SPA 模式。 - Vike 适合拥有独立后端、微前端需求或对部署灵活性有严格要求的团队。
- 对于 Next.js 开箱即用的图像优化、身份认证和缓存等功能，Vike 需要更多的手动配置。
什么是 Vike？
Vike（原名 vite-plugin-ssr）是一个 Vite 元框架，它为你提供基于文件的路由、SSR、SSG 和 SPA 模式 —— 而不会对你的后端、数据层或部署目标强加固定的设计观点。它自 2021 年起持续活跃开发，并被一些需要 Next.js 所无法提供的架构灵活性的组织用于生产环境。
关键区别在于：Vike 是为可组合性而设计的。你可以自带渲染库（React、Vue、Solid）、自带数据获取策略（TanStack Query、Apollo、原生 fetch）以及自带服务器（Hono、Express、Cloudflare Workers）。Vike 通过钩子系统将它们组合起来，而非强制约定。
Vike 与 Next.js 和 Nuxt 的不同之处
Next.js 和 Nuxt 是全能型框架。它们做了很强的假设：仅支持 React 或 Vue、特定的数据获取模式、紧耦合的部署模型。对于希望以最少配置快速推进的团队来说，这是一种合理的权衡。
Vike 做出了相反的取舍。它是一个带有扩展点的稳定核心，而非一个庞然大物。以下是这种差异在实践中的体现：
| 能力 | Next.js / Nuxt | Vike |
|---|---|---|
| UI 框架 | 仅支持 React / Vue | React、Vue、Solid 或自定义 |
| 按页面渲染控制 | 控制有限 | 通过 +config.js 按页面设置 SSR、SSG、SPA |
| 后端耦合 | 内置 API 路由 | Vike 可与任何后端协作 |
| 部署目标 | 针对 Vercel / Netlify 优化 | Node.js、Cloudflare Workers、Deno、Bun、自托管 |
| React Server Components | Next.js 中原生支持 | 通过 vike-react-rsc 扩展获得 |
| 数据获取 | getServerSideProps、loader | +data 钩子、TanStack Query 或自定义 |
其中按页面级别的渲染控制尤为实用。借助 Vike 的配置继承机制，你可以为产品页面声明 SSR，为管理后台启用 SPA 模式，为营销页面使用静态预渲染 —— 全部都在同一个项目内。
配合 Vike 的 UI 扩展（例如 vike-react），可以这样写：
// /pages/admin/+config.js
export default { ssr: false } // SPA
// /pages/(marketing)/+config.js
export default { prerender: true } // SSG
// /pages/product/+config.js
export default { ssr: true } // SSR
Discover how at OpenReplay.com.
什么时候适合使用 Vike
以下情况下，Vike 是一个不错的选择：
- 你有独立的后端（Python、Java、Laravel），无需框架来处理 API 路由
- 你需要部署灵活性 —— 运行在 Cloudflare Workers、自托管的 Node.js 或 Bun 上
- 你正在构建微前端，或需要在同一应用中混用 React 和 Vue 组件
- 你希望对架构拥有长期的控制权，而不被绑定到单一的托管平台
特别是对于 Vite SSR 这一使用场景，Vike 是目前能力最强的选项之一。最近的更新（如 Vike 的 +server 通用部署模型）进一步简化了在不同运行时和托管服务商之间的部署工作。
Vike 需要额外投入的地方
Vike 的灵活性是有实际代价的：
- 没有内置的图像优化 —— 你需要自行处理，或借助 CDN
- 生态较小 —— 相比 Next.js 或 Nuxt，现成的扩展更少
- 需要更多的手动接线 —— 身份认证、缓存和错误处理都需要显式配置
- React Server Components 相比 Next.js 仍处于实验阶段
如果你的团队希望在最少的基础设施决策中快速交付，Next.js 或 Nuxt 仍然能让你走得更快。
结论
Vike 并非旨在取代 Next.js 或 Nuxt —— 它解决的是不同的问题。如果你想要一个基于 Vite 的元框架，它不干涉你的架构决策，能与任何后端协作，并且让你对渲染和部署拥有精确的控制权，那么 Vike 已经具备生产就绪的能力，值得采用。如果你需要一个全托管、约定性强且拥有庞大插件生态的框架，请继续使用 Next.js 或 Nuxt。
如果你来自 React 背景，可以从 Vike 文档 和官方的 vike-react 扩展开始。
常见问题
直接的增量迁移并不容易，因为 Vike 使用了不同的路由和配置模型。大多数团队会在一个并行的项目中逐页迁移，复用 React 组件和业务逻辑，同时将路由和数据获取重写为 Vike 的 +config 和 +data 钩子。请规划一个集中的迁移窗口，而不是逐步替换。
Vike 通过 vike-react-rsc 扩展支持 RSC，但相比 Next.js（其中 RSC 是默认的渲染模型），它仍被视为实验性的。如果 RSC 对你的架构至关重要，Next.js 仍是更稳妥的选择。如果你只需要选择性的服务端渲染，Vike 的标准 SSR 钩子已经能覆盖大多数场景，无需 RSC 的复杂性。
Vike 与你自己的服务器运行时（Hono、Express、Fastify、Cloudflare Workers 等）协同工作，API 路由可以直接在该服务器中与渲染逻辑一同定义。这样可以让 API 层完全在你的掌控之中，并避免特定框架的约定。
是的，但要有合理的预期。Vike 自 2021 年起持续活跃开发，并被一些需要架构灵活性的团队用于生产环境。核心部分得到积极维护，但生态比 Next.js 或 Nuxt 小，团队需要自行组装身份认证、缓存和图像处理等功能，而不是依赖框架默认提供的方案。
Gain Debugging Superpowers
Unleash the power of session replay to reproduce bugs, track slowdowns and uncover frustrations in your app. Get complete visibility into your frontend with OpenReplay — the most advanced open-source session replay tool for developers. Check our GitHub repo and join the thousands of developers in our community.
