2026年8月18日，AI应用构建平台Lovable发布了一篇工程博客，详细披露了其将旗舰站点lovable.dev从Next.js迁移到TanStack Start的全过程。4200万月活用户、近400条路由、91万行非生成代码、150多个Agent工具、一个嵌入式IDE。一个月的并行运行、特性开关控制的渐进式迁移、90%以上的代码被提取为框架无关的共享层、绝大部分迁移PR由AI Agent起草并合入、一个11分钟的OOM生产事故。 这不是一次实验性的技术尝鲜，这是一次在千万级用户面前完成的框架迁移。
一、为什么一个4200万月活的平台要换框架？
Lovable是一个AI驱动的应用构建平台，用户用自然语言描述需求，平台生成完整的Web应用。Lovable.dev本身就是这个平台的旗舰展示——一个拥有4200万月活用户的AI产品，包括对话式构建界面、实时预览、代码编辑器、部署管理等功能。
在此之前，lovable.dev的技术栈是Next.js部署在Vercel上。这是一个非常“标准”的选择：Next.js是当前最主流的React全栈框架，Vercel是它的原生部署平台。对于大多数团队来说，这个组合“够用而且好用”。
那为什么要迁移？
Lovable团队在博客中给出的理由非常直接：Lovable正在变成一个应用托管平台，而lovable.dev本身应该成为这个平台上的“一个普通应用”。
Lovable的核心业务是“让用户构建并部署应用”。它有自己的运行时环境、自己的部署管道、自己的边缘基础设施（基于Cloudflare）。lovable.dev跑在Vercel上，意味着平台的旗舰应用和平台本身在基础设施层面是分离的。
“Eat your own dog food” ——Lovable选择把自己的官网变成平台上的一个用户应用。当lovable.dev跑在Lovable自己的基础设施上时，它的每一次性能瓶颈、每一个运行时bug都会直接反馈到平台的改进循环中。Futurum Group的分析指出，这是一种 “垂直整合”策略：通过把自己的旗舰站点作为平台上的一个压力测试用例，Lovable可以用超大规模的真实负载来验证和驱动平台演进。
而TanStack Start被选中，是因为Lovable的新项目生成器从2026年5月起就默认输出TanStack Start。用户在Lovable上构建的应用跑在TanStack Start上，那lovable.dev本身也应该跑在同样的运行时里。
二、规模数据：91万行代码、400条路由、150个Agent工具
先感受一下这个应用的体量。
根据Lovable工程博客和Futurum Group的分析，lovable.dev拥有：
- 4200万月独立访客
- 近400条路由
- 91万行非生成代码（注意，这是“非生成”代码——不包括AI生成的用户应用代码）
- 150多个Agent工具
- 一个带语法高亮的嵌入式IDE
这不是一个“官网”或者“营销页面”。这是一个完整的SaaS产品：用户登录、创建项目、与AI对话、查看实时预览、编辑代码、部署应用。它的前端需要处理WebSocket连接、代码编辑器的语法树解析、实时预览的沙箱渲染、以及一个完整的对话式AI界面。
在这样的规模上迁移框架，风险不是“页面会不会崩”，而是“整个产品会不会宕机”。
三、迁移策略：不是“重写”，是“剥离”
Lovable团队没有选择“从零重写”，也没有选择“一次性切换”。他们设计了一套分层的迁移策略。
3.1 并行运行六个月
从2026年初开始，Next.js和TanStack Start在同一个生产环境中并行运行了六个月。这不是“在本地跑两个版本对比”，而是“真实用户被路由到两个不同的框架上”。
技术上，他们使用了一个代理Worker来路由流量。这个代理根据用户所在的“旅程分组”（journey group）来决定请求走Next.js还是TanStack Start。特性开关控制渐进式放量：先让内部团队切换，再让一小部分用户切换，然后逐步扩大到全量。
并行运行的核心价值是：如果TanStack Start版本出了问题，流量可以瞬间切回Next.js。 迁移不是“要么全有要么全无”的赌博，而是一个可回滚的渐进过程。
3.2 把90%的代码变成“框架无关”
这是整个迁移中最聪明的设计决策。
Lovable团队没有把“Next.js代码”翻译成“TanStack Start代码”。他们做的是把业务逻辑和UI从框架中剥离出来，提取到一个框架无关的共享层。
具体做法是使用基于接口的适配器（interface-based adapters） 。比如，数据获取逻辑不直接调用Next.js的getServerSideProps或者TanStack Start的loader，而是定义一个DataFetcher接口，然后为两个框架分别提供适配器实现。
迁移完成后，框架特定的代码只占Web代码库的3%，而90%到95%的代码是框架无关的共享代码。
这意味着什么？框架变成了一个“可替换的外壳” 。业务逻辑、UI组件、状态管理、数据流——这些才是应用的核心价值——被保护在框架无关的抽象层里。Next.js和TanStack Start只是这个核心的不同“渲染后端”。
如果未来再换一次框架，迁移成本会远低于这一次。
四、AI Agent主导了迁移：没有专门的迁移团队
Lovable的博客中有一个细节非常值得注意：这次迁移“绝大部分由Agent完成”，最终“不需要专门的迁移团队” 。
Lovable本身就是一个AI应用构建平台，它有自己的Coding Agent。在这次迁移中，团队大量使用了AI Agent来起草和合入迁移PR。
但Agent主导迁移的前提，是前面的“框架剥离”工作做得好。
因为90%以上的代码是框架无关的，Agent只需要处理那3%的框架适配层。Agent不需要理解“Next.js的App Router和TanStack Start的路由有什么区别”这样的深层问题——它只需要把适配器从一个实现换到另一个实现。
Agent擅长的是“在明确的边界内执行机械性转换”。框架剥离创造的，正是这样一个边界。
如果代码是深度耦合在Next.js里的——到处是next/link、next/image、next/navigation、Server Components的特殊语法、Vercel特定的环境变量——那Agent面临的就不是“适配器替换”，而是“语义翻译”，出错率会高得多。
Lovable的迁移方法论可以总结为一句话：先做人做的抽象，再让Agent做机械的替换。
五、一个11分钟的OOM事故
迁移不是一帆风顺的。
Lovable团队披露了一个生产事故：在迁移过程中，发生了一次持续11分钟的内存溢出（OOM）事故。原因是V8 isolate的内存限制被触发了。
Cloudflare Workers运行在V8 isolate上，每个isolate有固定的内存上限。lovable.dev在Next.js上的一些模块——可能是大型依赖、复杂的服务端渲染逻辑、或者内存缓存——在V8 isolate的约束下超出了限制。
团队通过多项内存优化解决了这个问题。具体的优化细节没有完全披露，但可以推测包括：减少服务端bundle体积、优化依赖、调整缓存策略、将部分内存密集型逻辑移到Worker之外。
11分钟对于4200万月活的平台来说，影响是真实的。 但关键在于，因为并行运行和特性开关的存在，团队可以快速定位问题并修复，而不是“整个平台宕机然后紧急回滚”。
六、迁移后的收益：本地开发快7倍、TTFB降49%
迁移完成后的数据，是Lovable选择公开这次案例的底气。
本地开发体验
TanStack Start的本地开发服务器在10秒内启动，占用1.5GB内存。相比之下，Next.js的本地开发服务器需要70秒启动，占用8GB内存。
启动速度相差7倍，内存占用相差5倍多。
对于一个拥有91万行代码的复杂应用来说，这个差距意味着开发者的“等待时间”从“泡杯咖啡”变成了“几乎感觉不到”。这不是一个微小的改进，这是工作流层面的质变。
生产性能
迁移后，中位TTFB（Time to First Byte）下降了49% 。CI构建时间从12分钟以上缩短到6到9分钟。
TTFB降低49%意味着什么？用户点击链接后，看到服务器响应的速度几乎快了一倍。对于4200万月活的平台来说，这是一个直接转化为用户体验和留存指标的改进。
AI Agent表现
Lovable团队还观察到一个有趣的结论：TanStack Start对AI Agent更友好。
原因在于训练语料。Next.js经过多年的生态扩张，积累了大量的抽象层和“隐式行为”——Server Components和Client Components的边界、App Router的约定式路由、Vercel特定的部署行为。这些抽象对人类来说需要学习，对AI Agent来说则意味着更多的不确定性和更少的“可预测的正确输出”。
TanStack Start的抽象更少、更显式、更接近标准React。对于AI Agent来说，更小、更一致的训练语料意味着更低的幻觉率和更高的代码生成准确率。
这不是“TanStack Start比Next.js更好”。这是“不同的框架对AI的友好程度不同”。
七、这对前端开发者意味着什么？
1. 框架迁移是可以“工程化”的
Lovable的案例证明了一件事：在生产环境迁移一个4200万月活的应用，不需要停机，不需要重写，不需要专门的迁移团队。
前提是你有正确的策略：并行运行、特性开关、框架剥离、Agent执行。这套方法论可以复用到任何“从框架A迁移到框架B”的场景。
2. “框架无关”不是理想主义，是工程实践
90%以上的代码被提取为框架无关的共享层——这是Lovable迁移成功的核心。它把一个“框架迁移问题”转化成了“适配器替换问题”。
对于任何长期维护的前端项目来说，这都值得借鉴：不要把业务逻辑深埋在框架特定的API里。定义接口，提供适配器，让框架成为可替换的“外壳”。
3. AI Agent的能力边界，取决于你给它划的边界
Lovable的Agent能高效完成迁移，不是因为Agent“更聪明”，而是因为Lovable把问题简化成了Agent能处理的形式。
如果代码是深度耦合的，Agent需要做“语义翻译”，出错率会高。如果代码已经被剥离成框架无关的共享层+薄适配器，Agent只需要做“机械替换”。
Agent的能力，取决于你如何设计它需要解决的问题。
4. 框架选型的新维度：AI友好度
Lovable团队明确提到，TanStack Start对AI Agent更友好，因为它的训练语料更小、更一致。
这可能是2026年框架选型中一个正在上升的维度：这个框架的抽象层是否足够“可预测”？AI Agent能不能可靠地生成正确的代码？当你的团队开始用Coding Agent辅助开发时，框架的“AI友好度”会直接影响开发效率。
写在最后
2026年8月18日，Lovable用一篇工程博客披露了一次教科书级的生产环境框架迁移。
4200万月活、91万行代码、400条路由。六个月的并行运行、特性开关控制的渐进式切换、90%以上的代码被提取为框架无关的共享层、绝大部分迁移PR由AI Agent完成、一个11分钟的OOM事故、最终中位TTFB下降49%。
这不是“Next.js不好”或者“TanStack Start更好”的故事。这是一个关于“如何在一个活着的生产系统上做架构演进”的故事。
核心方法论只有三条：并行运行，可回滚；框架剥离，让框架成为外壳；Agent执行，人做抽象。
当你把框架变成可替换的，迁移就从一个“冒险”变成了一个“工程问题”。
评论区聊聊：你的项目在框架上耦合有多深？如果明天要换框架，你有多少代码是“框架无关”的？
