从 Vite 迁移到 Next.js：一个 SaaS 的真实复盘
译注：本文翻译自 dev.to 文章《Why I Migrated My SaaS from Vite to Next.js — And What It Meant for My Users》，作者为 digitaldev，原文发布于 2026 年 9 月 18 日。原文链接见文末。文中观点与数据均来自作者自述，编译时保持原意，未作事实补充。
框架选择的困境
作者回忆，最初以副业项目形式启动这款 SaaS 时，唯一的衡量标准是开发速度。他选择了 Vite，因为它的热模块替换（HMR）几乎瞬时完成，配置极简，对 React 开发者而言像是 Create React App 的自然演进。
但随着用户规模增长、SEO 需求变得复杂，他遇到了瓶颈。上个月，他终于决定将整个技术栈迁移到 Next.js。文章围绕这一选择的动因、遇到的技术障碍，以及对终端用户体验的实际影响展开。
一、客户端渲染的 SEO 天花板
Vite 默认提供的是单页应用（SPA）。对于登录墙后的仪表盘而言，这无可厚非。但对 SaaS 来说，落地页、博客文章和公开文档才是命脉。
作者指出，尽管 Googlebot 对 JavaScript 的抓取能力有所提升，但他发现社交分享预览（Open Graph 标签）表现不稳定。由于 HTML 在 JS 执行前基本为空，Twitter、LinkedIn 等平台常常无法抓取到元数据。迁移到 Next.js 后，他可以使用服务端渲染（SSR）和静态站点生成（SSG），确保每个页面抵达浏览器时已完整成形，并带有正确的 meta 标签。
二、性能：FCP 与 TTI 之别
在作者的 Vite 构建中，初始包体积逐渐攀升至 400kb（gzip 后）。即便做了代码分割，用户仍会在主包解析期间看到短暂的白屏或加载动画，这影响了首次内容绘制（FCP）。
Next.js 通过以下方式改善了这一点：
- 自动代码分割：只加载当前页面所需的 JavaScript。
- 图片优化：
next/image组件自动提供 WebP 格式和调整尺寸后的资源。 - 流式渲染：HTML 分块就绪即发送，让站点感觉明显更迅捷。
三、前端内置后端的迷思
作者在 Vite 方案中最大的摩擦点之一，是仅为了发送事务性邮件或处理 Stripe webhook 这类小任务，就得单独维护一个 Express.js 后端。
借助 Next.js 的 API Routes，他得以删除独立的后端仓库。将 API 逻辑与 UI 组件放在同一个 monorepo 中（使用 /app 或 /pages/api 目录），降低了部署复杂度，也简化了 CI/CD 流程。
四、迁移策略
迁移生产应用不只是改几处 import。作者不得不重新思考数据获取方式：从客户端 useEffect 钩子拉取数据，转向 getServerSideProps（并最终在 App Router 中使用 Server Components）。
他提到，如果面临类似过渡又担心手动样板代码，可以借助 ViteToNext.AI 这类工具，将 Vite + React 组件自动化迁移到 Next.js 结构，节省大量文件重构时间。
五、对用户意味着什么
迁移之后，指标给出了清晰的答案：
| 指标 | 变化 |
|---|---|
| 跳出率 | 落地页下降 12%，可能与首屏加载更快有关 |
| 搜索可见度 | 前 30 天自然曝光量增长 20%，页面索引更准确 |
| 用户感知 | 加载状态的“闪烁”被即时内容取代，应用显得更“高级” |
结论
作者认为，Vite 对内部工具和纯 SPA 而言仍是出色的工具。但对于需要在搜索引擎中竞争、并提供精致首屏体验的 SaaS，Next.js 提供了原始构建工具所不具备的基础设施。迁移投入了大量时间，但 SEO 和用户留存上的回报已让这一切值得。