越来越多团队正在逃离 Next.js，他们去了哪儿？
过去这一两年，React 圈子里反复出现过类似的标题：
“我们如何把本地开发时间砍掉 83%” “把生产前端搬离 Next.js，构建从 10 分钟变 2 分钟” “几个小时迁移了 178 个文件”
主角几乎都是同一个新框架——TanStack Start。
Next.js 当了这么多年的”React 全栈默认选项”，怎么突然就有人开始集体”跑路”了？谁在迁移、为什么迁、TanStack Start 到底好在哪，以及一个很多人最关心的现实问题——离开了 Next.js + Vercel 这套组合，部署会不会变得很麻烦？下面一个一个拆开看。
不过有个最重要的前提得先摆在前面，免得看完热血上头就去重构生产项目：
截至 2026 年年中，TanStack Start 还没发正式的 1.0 稳定版，仍然挂着 “RC”（候选发布版）的牌子。 它的作者 Tanner Linsley（就是 React Query / TanStack Query 那位）在 2025 年 9 月宣布进入 v1.0 RC，说”功能已经齐了、API 稳定了”，但到现在官网、文档都还写着 RC。
这点很关键，后面会反复提到。
一、到底是谁在”跑路”？
光说”很多人迁移”是不负责任的。下面几个案例有名有姓，还甩出了真实数据。
Inngest：被本地开发”慢哭了”的团队
Inngest 是做事件驱动工作流的平台。他们的工程师在 2026 年初写了篇博客，标题直接就是”把本地开发时间砍掉 83%：我们为什么离开 Next.js”。
这个故事特别有代入感。团队很早就 all-in 了 Next.js 的 App Router 和 RSC（React 服务端组件），结果发现对一个人手不多、一人身兼数职的小团队来说，"use client"、"use server" 这些指令、还有那套分层缓存，心智负担越堆越高。
最要命的是本地开发——首屏加载动不动就要 10 到 12 秒。团队 Slack 里全是哀嚎：“我恨死这玩意了”、“前端太 TM 慢了”。
挣扎也试过：升级 Next.js、用 Vercel 的性能分析工具、两次上 Turbopack……都只快了几秒，杯水车薪。
最后一咬牙，一个工程师带着 AI 工具，几周时间一次性重写完。结果用他们自己的话说：“现在很少见到首屏超过 2、3 秒，而且只有某条路由第一次打开时才这样。Slack 里的画风变成了——‘这也太丝滑了吧！’”
这是目前最纯粹、最完整的一个”整框架搬家”案例。
Particl：一个中型应用的冷静选择
Particl 是做零售价格追踪的。工程师 Kyle Gill 在 2025 年 3 月说，他们”尽可能把代码搬离了 Next.js”。
这是个不小的应用：20 万行代码、约 750 个文件、100 来个页面。他列的”分手理由”很有共鸣：Vercel 的费用、App Router”到处是坑”、那三层缓存（完整路由缓存、数据缓存、路由缓存）根本没法调试、好多 API 还挂着 “experimental” 的标签、最惨的时候本地编译要等两分钟。
但 Kyle 有句话值得每个想跟风的人抄下来贴墙上：
“别为了迁移而迁移。如果你的 Next.js 跑得好好的、团队也顺手、没踩什么大坑，那就待着别动。框架迁移很贵，而且对面的草不一定更绿。“
Railway：规模最大的一次”明牌”迁移
Railway 是个开发者云平台。2026 年 4 月，他们官方博客发了篇”把 Railway 前端搬离 Next.js”。
这次的体量是真的大：整个生产前端——控制台、画布、官网——服务着数百万用户、跨 200 多条路由，他们用两个 PR、零停机搬完了。
数据也很硬：“以前要 10 分钟以上的构建，现在两分钟内搞定。“博客里还补了一刀：“其中 6 分钟纯粹是 Next.js 拖的，有一半时间卡在 ‘finalizing page optimization’ 上。”
这里得说句公道话：Railway 和 Particl 严格来说主要是搬到了 Vite + TanStack Router（路由库 + 构建工具），不完全等于上了完整的 TanStack Start 框架——因为它们都是重客户端的应用。不过这是同一个生态，大家也都拿它当标志性案例。真正”整框架搬家”的代表还是 Inngest。
除了这几家，Medium、掘金、dev.to 上还有一堆个人开发者的迁移记录，但没具名公司的，参考价值有限。
二、TanStack Start 到底香在哪？
聊完”谁在跑”，该聊”为啥跑”了。
一句话概括两者的根本区别
这是理解所有分歧的钥匙：
- Next.js 是”服务端优先”的。它默认让你用 RSC 思考，脑子里得装着”服务端组件”和”客户端组件”两种东西，而且和 Vercel 平台绑得很深。
- TanStack Start 是”客户端优先”的。默认就是个 SPA（单页应用），需要服务端能力时再”显式地”开启。心智模型只有一件事：一个客户端应用，通过类型安全的调用去访问后端。
官方有句话说得挺直白：Next.js 优化的是”Vercel 心目中 Web 应该长的样子”，而 TanStack Start 优化的是”开发者的掌控感和正确性”。
香点一：类型安全，这是它的看家本领
这是 TanStack 最能打的地方。它的路由会在构建时就生成一整棵带类型的路由树——路由参数、URL 上的查询参数（还能用 Zod 校验）、数据加载函数的返回值，全都被 TypeScript 自动推断好了，基本不用手写类型。连写个跳转链接 /users/$userId 都是带类型校验的。
写过大型 TS 项目的人应该懂，这种”改了一处、全链路飘红提醒你”的体验有多省心。
香点二：快，是真的快
底层是 Vite，所以开发服务器启动、热更新都快得离谱。前面三个案例的提速数据已经说明问题了。官方还做过 SSR 性能优化，在并发测试里吞吐量提升了大约 5.5 倍。
香点三：不被任何云厂商绑架
这是核心卖点之一。Next.js 是 Vercel 家的，新特性往往先在 Vercel 上体验最好——这不是阴谋论，这就是人家的商业模式。
而 TanStack Start 靠 Vite + Nitro，理论上能部署到任何 JS 运行环境。Kyle Gill 那句话很到位：“TanStack 不会因为我用它的 API 部署而赚到一分钱。“——意思是它没有动机把人锁死。
那它有没有坑？当然有
吹归吹，坑也得摆出来：
- 还没 GA。前面说了，它还是 RC，没经过多年大规模生产捶打。
- 生态小。Next.js 那种开箱即用的图片/字体优化它没有（得装插件）；遇到问题能搜到的答案、能招到的熟练工，都远少于 Next.js。
- 不适合纯内容站。营销官网、博客这种重 SEO、偏静态的站，上 TanStack Start 反而是找麻烦，不如用 Astro 或干脆静态生成。
- 出过一次安全事故。2026 年 5 月，TanStack 的 npm 包遭遇过一次供应链攻击，有人发布了一批恶意版本（好在二十多分钟就被研究员发现处置了）。这提醒一件事：上生产一定要锁死依赖版本。
一句话决策： 做后台、SaaS、仪表盘这类重交互、数据驱动的应用，又看重类型安全、想躲开厂商锁定，可以认真考虑它；做内容站、要成熟生态和好招人，那还是 Next.js 稳。
三、最现实的问题：离开 Vercel，部署会很痛苦吗？
很多人犹豫，核心就卡在这：Next.js + Vercel 那套一键部署、自动预览、边缘函数实在太爽了，换了框架是不是就得自己折腾运维？
好消息是——完全不会，甚至可能更自由。
关键在于 TanStack Start 底层用了 Nitro 这个”万能转接头”。想部署到哪，改一个配置（preset）就行，代码基本不用动。
几条现成的路摆在下面：
想继续用 Vercel？照样可以。 在配置里加一行 nitro() 插件就行，Vercel 官方文档都写了”配合 Nitro 跑得很好”。自动预览、CI/CD、CDN、边缘函数一个不少，还能用上 Vercel 的弹性计费（按用量付费，空闲不花钱）。换句话说，用 TanStack Start 不等于放弃 Vercel 的爽感。
想要全球边缘？上 Cloudflare Workers。 配好 wrangler.toml，一条 wrangler deploy 能自动识别项目。服务端函数会编译到 Workers 跑在全球边缘节点，这一点甚至比 Vercel 的单区域部署更有优势。
想要最省心的 Git 工作流？选 Netlify。 它从 2025 年 3 月起就是官方合作伙伴，装个官方插件，连上仓库，push 就部署，预览环境自动有。
想完全自己掌控、顺便省钱？自托管。 用 node-server 这个 preset，构建完 node .output/server/index.mjs 就能跑；套个 Docker 镜像，丢到 Railway、Render、Fly.io 或任意一台服务器上都行。
门道就在这：Next.js 是把这些能力”焊死”在框架 + Vercel 里；而 TanStack Start 是把它们交给托管平台。 所以应用能在 Vercel、Cloudflare、Netlify、自建之间随便横跳，代码一行不改。这才是”不被绑架”真正落地的样子。
最后，几句实在话
到底该不该把项目迁过去？
新项目，如果是重交互的后台/SaaS/工具类，团队又喜欢 TanStack 那一套、在意类型安全，可以大胆试，部署直接挂 Cloudflare 或 Netlify，体验很顺。但如果是内容站，别凑这个热闹。
现有的 Next.js 项目，请把 Kyle Gill 那句话再读一遍——别为迁移而迁移。只有当一个团队真的天天被 App Router 的复杂度、慢到想砸键盘的本地构建、调不明白的缓存折磨，或者 Vercel 的账单/锁定真成了问题，才值得动手。一个简单的判断标准：本地开发服务器编译总要等上五秒十秒、团队反复在 RSC 和缓存的边界上栽跟头，那就可以认真评估了。
毕竟它还是 RC，生产环境务必锁版本、盯着更新、对实验特性（比如它的 RSC 支持）留个心眼。等它正式发 1.0、等周边的登录/支付/CMS 这些生态再成熟点，风险会小很多。
技术选型从来不是追新，而是看它能不能解决当下真实的痛。Next.js 不是变坏了，只是它不再是唯一答案了——这本身，就是件好事。
本文基于截至 2026 年中的公开信息整理。文中提到的提速数字（83%、5.5 倍等）大多来自各团队自述，测试环境各不相同，不宜当成普适基准；TanStack 生态变化很快，文中的配置和版本信息可能很快就过时。做选型时请以官方最新文档为准。