Lovable 把 React+Vite 換掉了，用 TanStack Start 重構後每週跑出 100 萬個應用
整理版優先睇
Lovable 由 React+Vite SPA 轉用 TanStack Start，每週生成 100 萬個項目，SEO 同 AI 流量顯著提升
呢篇文章係由 Lovable 嘅技術團隊分享，佢哋係一個 AI 應用生成平台，用戶描述需求就自動生成前端代碼兼部署。目標用戶係獨立開發者同非技術創業者，最緊要快。佢哋遇到嘅問題係原本用 React + Vite 嘅 SPA 令 SEO 接近零、社交分享預覽失效，同埋服務器邏輯要另外搞 Edge Functions，好碎件。整體結論係佢哋轉咗用 TanStack Start 做預設框架，發現呢個選擇解決咗上述問題，仲帶來咗可觀增長。
遷移之後，有機搜索流量增長咗 2.9%，AI 工具流量（例如 ChatGPT、Perplexity）更加爆升 98.5%。背後的關鍵係 SSR 令爬蟲讀到完整內容，而 TanStack Start 顯式嘅服務器/客戶端邊界（用 createServerFn()）仲幫到 AI 模型減少出錯。佢哋嘅選型標準係保留 React 生態、開源、支援 SSR、唔綁定平台；無揀 Next.js 係因為 Cloudflare 相容問題同埋服務器邊界唔夠清晰。
對於開發者嚟講，呢個案例顯示 TanStack Start 喺真實生產環境嘅表現，特別係配合 Cloudflare Workers 嘅部署。而家 TanStack Start 仲支援 Rsbuild 2，進一步減低對打包工具嘅依賴。如果唔想被平台綁死又需要全棧能力，呢個值得留意。
- Lovable 將默認框架由 React+Vite SPA 轉為 TanStack Start，每週生成超過 100 萬個 TanStack Start 項目。
- SPA 導致 SEO 接近零、社交預覽失效，服務器邏輯碎片化，係轉型主因。
- 揀 TanStack Start 而非 Next.js，因為 Cloudflare 相容性更好，而且 createServerFn() 令服務器/客戶端邊界顯式，AI 生成代碼更少出錯。
- 遷移後有機搜索流量升 2.9%，AI 工具流量升 98.5%，反映結構化 HTML 對新內容入口好重要。
- TanStack Start 而家支援 Rsbuild 2，唔再綁 Vite，進一步強化「唔綁任何工具」嘅路線，適合想避開平台鎖定嘅開發者。
點解要轉框架？SPA 嘅死穴
Lovable 係一個 AI 應用生成平台，用戶用口語描述需求，系統就自動生成前端代碼兼部署。用戶以獨立開發者同非技術創業者為主，目標係快。原本用 React + Vite 嘅 SPA 喺大部分場景無問題，但隨住用戶增多，幾個死穴浮現咗。
SEO 幾乎係零
SPA 畀爬蟲嘅只係空殼 HTML，核心內容要靠 JavaScript 執行先出現。Google 爬蟲雖然識行 JS，但平均延遲約 10 秒；其他爬蟲直頭跳過。
社交分享預覽失效
用戶將產品連結分享出去，社交平台爬蟲讀唔到動態插入嘅 meta 標籤，預覽一片空白。
服務器邏輯碎片化
SPA 想做數據庫操作，要額外部署 Edge Functions，變相維護兩套獨立系統，除錯同部署都好麻煩。
點解揀 TanStack Start 而唔係 Next.js？
Lovable 嘅選型好清楚：必須保留 React 生態、開源、支援 SSR、有成熟團隊維護。Next.js 紙面上符合，但佢哋最終無揀，原因有兩個。
服務器/客戶端邊界顯式
TanStack Start 嘅 createServerFn() 令開發者清楚標記服務器函數，編譯時自動拆成服務器包同客戶端包。呢個機制幫 AI 模型減少「將服務器代碼擺喺瀏覽器執行」嘅低級錯誤。Lovable 仲同 TanStack 團隊合作維護咗一套 AI 工具規範，專門處理模型用過時模式（例如用 getServerSideProps 寫 TanStack 代碼）嘅問題。
架構點樣改？
舊架構係 Cloudflare Pages 靜態託管 SPA，數據庫經獨立 Edge Functions 處理。新架構全面搬去 Cloudflare Workers，TanStack Start 喺請求到來時喺服務器執行 React 樹，流式返還完整 HTML。
兩種渲染模式按路由選擇
- 靜態內容（例如博客文、落地頁）喺發佈時預生成平面 HTML，唔行 SSR。
- 動態頁面按需服務端渲染，兩種模式互不幹擾。
服務器密鑰由環境變量改為 Cloudflare Workers 綁定注入，同代碼完全解耦，修改密鑰唔使重新構建，即時生效。用戶端體驗不變，一鍵發布，系統自動完成構建、靜態預生成同 Worker 部署。
轉用之後嘅效果
博客入面畀咗兩個核心數字：有機搜索流量增長 2.9%，AI 工具流量（例如 ChatGPT、Perplexity）增長 98.5%。
2.9% 對 SPA 出身嘅平台嚟講係由無到有
之前 SSR 未上線時，呢塊流量接近零。AI 工具流量接近翻倍，反映結構化 HTML 對新世代內容入口嘅重要性愈來愈高。值得一提係 Lovable 無強制遷移舊項目，只係額外畀咗爬蟲預渲染優化；新項目先默認用 TanStack Start。
框架本身嘅進化：唔再綁打包工具
同一時間，TanStack 官方宣佈 TanStack Start 而家支援 Rsbuild 2，同 Vite 並列。即係話完整嘅 Start 功能可以喺 Rspack / Webpack 生態運行，原本只能用 Vite 嘅限制打開咗。
TanStack 作者 Tanner Linsley 話做到「與打包工具無關」係下一個層次挑戰
呢個表態顯示產品取向係唔綁 UI 庫、唔綁打包工具、唔綁部署平台。對應用生成平台呢類需要長期押注底層框架嘅場景，「唔被鎖死」係最值錢嘅賣點，亦解釋咗 Lovable 點解揀佢。
AI 應用生成平台 Lovable 靜靜雞將默認框架換咗。由 React + Vite 嘅單頁應用（SPA），轉咗去 TanStack Start。轉咗之後，用戶每星期喺平台上面整出嚟嘅 TanStack Start 項目超過 100 萬個。
呢個唔係某個小團隊喺度試新技術，而係一個有規模嘅生產系統完成咗框架搬遷，而且已經喺度運行緊。對於仲喺度觀望 TanStack Start 嘅開發者嚟講，呢個信號值得認真睇一睇。
Lovable 係做乜嘅？
Lovable 係一個 AI 應用生成平台，用戶描述需求，平台會自動整出前端代碼同埋部署上線。用家以獨立開發者同非技術創業者為主，追求嘅係由諗法到用得嘅產品嘅時間愈短愈好。
正因為咁，Lovable 嘅框架選擇直接影響咗佢每日輸出嘅大量項目。今次轉換，唔單止係內部技術棧升級，亦都等於將 TanStack Start 推到咗真實嘅大規模壓力測試環境入面。
SPA 喺呢個場景之下行唔鬱喇
React + Vite 整出嚟嘅 SPA 喺絕大多數場景之下冇問題，但 Lovable 遇到嘅幾個問題將呢條路塞死咗。
SEO 幾乎係零。用戶通過平台整出產品之後，通常希望俾搜索引擎發現。但 SPA 俾爬蟲嘅係空殼 HTML，核心內容要靠 JavaScript 執行之後先至出現。Google 嘅爬蟲雖然識得行 JS，平均延遲大約 10 秒，其他爬蟲基本上直接跳過。
社交分享預覽失靈。用戶將產品連結發出去，期望見到有內容嘅預覽卡片。SPA 嘅 meta 標籤係動態插入嘅，社交平台嘅爬蟲讀唔到，預覽一片空白。
伺服器邏輯碎片化。SPA 裏便想做資料庫操作，只能另外部署 Edge Functions，等於維護兩套獨立嘅嘢，調試同部署都係負擔。
點解揀 TanStack Start 而唔係 Next.js
呢個係成件事裏面最值得關注嘅部分。
Lovable 嘅選擇標準列得好清楚：必須保留 React 生態、開源唔綁定平台、支援 SSR、有成熟團隊維護。Next.js 喺紙面上滿足呢啲條件，但佢哋最終冇揀。
原因之一係部署平台。Lovable 用嘅係 Cloudflare，Next.js 喺 Cloudflare Workers 上面嘅支援一向係個麻煩事，而 TanStack Start 嘅設計由一開始就冇平台綁定。
原因之二同 AI 代碼生成直接相關。TanStack Start 嘅伺服器/客戶端邊界非常顯式，開發者用 createServerFn() 標註伺服器函數，編譯時自動將佢拆成兩個包：
伺服器包：保留原始處理邏輯 客戶端包：替換成型態化嘅 fetch 存根
呢個機制令 AI 模型更難犯"將伺服器代碼行喺瀏覽器裏面"呢種低級錯誤。Lovable 甚至同 TanStack 團隊合作維護咗一套專用嘅 AI 工具規範，專門處理模型因為訓練截斷而用過時模式嘅問題，例如用 Next.js 嘅 getServerSideProps 寫 TanStack Start 代碼。
架構改咗啲乜
舊架構：Cloudflare Pages 靜態託管 SPA，資料庫操作通過獨立 Edge Functions 處理。
新架構：整體搬過去 Cloudflare Workers，TanStack Start 喺請求到嚟嘅時候喺伺服器側執行 React 樹，流式返回完整 HTML。
靜態內容（博客文章、登陸頁）喺發佈嘅時候預先生成平面 HTML，唔行 SSR。動態頁面按需要伺服器端渲染。兩種模式按路由選擇，互不幹擾。
伺服器密鑰嘅管理方式都變咗。原本靠環境變量，而家作為 Cloudflare Workers 綁定注入，同代碼包完全解耦。修改密鑰唔需要重新構建，即時生效。
用戶端體驗冇變化，撳發布，系統自動完成構建、靜態路由預生成、Worker 部署，唔需要手動配置任何嘢。
轉咗之後數據點樣
博客入面畀咗兩個核心數據：
有機搜索流量：預渲染頁面增長咗 2.9% AI 工具流量（ChatGPT、Perplexity 等）：增長咗 98.5%
2.9% 睇落唔大，但對於一個以 SPA 起家嘅平台嚟講，呢個係由無到有。SSR 之前，呢塊流量接近零。
AI 工具流量差唔多翻倍，背後係結構化 HTML 對新一代內容入口嘅重要性喺度快速提升。Perplexity、ChatGPT 呢類工具抓取頁面嘅時候，可以讀到完整內容，SPA 時期同樣係讀空殼。
值得一提嘅係，Lovable 並冇強制搬遷舊項目。已經有嘅應用繼續用原本嘅架構，只係額外獲得咗爬蟲預渲染優化。新建立項目先默認用 TanStack Start，完整嘅搬遷路徑仲喺度推進緊。
框架自己都喺度向外擴展
Lovable 轉換嘅同一時間，TanStack 官方都發咗條動態：TanStack Start 而家支援 Rsbuild 2，同 Vite 並列。即係話，完整嘅 Start 功能集延伸到咗 Rspack / Webpack 生態，原本淨係用得 Vite 嘅限制被打開咗。
TanStack 作者 Tanner Linsley 喺轉發時講得好直白，團隊一直以"構建同 UI 框架無關嘅軟件"為傲，而做到"同打包工具無關"係下一個層次嘅挑戰。呢個表態背後係一個清晰嘅產品取向：唔綁 UI 庫，唔綁打包工具，亦都唔綁部署平台。對應用生成平台呢種需要長期押注底層框架嘅場景，"唔俾鎖死"恰恰係最值錢嘅嘢，呢個亦解釋咗 Lovable 當初點解揀佢。
對於仲喺度評估全棧框架嘅 Node.js/前端開發者，TanStack Start 嘅核心賣點清楚：React 生態完全兼容，SSR 原生支援，Cloudflare/Vercel/Node.js 都可以部署，伺服器/客戶端邊界顯式清晰。唔想俾平台綁死又需要全棧能力，又多咗一個新選擇。
AI 應用生成平台 Lovable 悄悄把默認框架換掉了。從 React + Vite 的單頁應用（SPA），切到了 TanStack Start。切換之後，用戶每週在平台上生成的 TanStack Start 項目超過 100 萬個。
這不是某個小團隊在測試新技術，而是一個有規模的生產系統完成了框架遷移，並且已經在跑。對於還在觀望 TanStack Start 的開發者來說，這個信號值得認真看一眼。
Lovable 是做什麼的
Lovable 是一個 AI 應用生成平台，用戶描述需求，平台自動生成前端代碼並部署上線。使用者以獨立開發者和非技術創業者為主，追求的是從想法到可用產品的時間儘可能短。
正因如此，Lovable 的框架選型直接影響了它每天輸出的海量項目。這次切換，不只是內部技術棧升級，也等於把 TanStack Start 推到了真實的大規模壓力測試環境裏。
SPA 在這個場景下跑不動了
React + Vite 生成的 SPA 在絕大多數場景下沒有問題，但 Lovable 遇到的幾個問題把這條路堵死了。
SEO 幾乎是零。用戶通過平台生成產品之後，往往希望被搜索引擎發現。但 SPA 給爬蟲的是空殼 HTML，核心內容靠 JavaScript 執行後才出現。Google 的爬蟲雖然能跑 JS，平均延遲約 10 秒，其他爬蟲基本直接跳過。
社交分享預覽失效。用戶把產品連結發出去，期待看到有內容的預覽卡片。SPA 的 meta 標籤是動態插入的，社交平台的爬蟲讀不到，預覽一片空白。
服務器邏輯碎片化。SPA 裏想做數據庫操作，只能另外部署 Edge Functions，等於維護兩套獨立的東西，調試和部署都是負擔。
為什麼選 TanStack Start 而不是 Next.js
這是整件事裏最值得關注的部分。
Lovable 的選型標準列得很清楚：必須保留 React 生態、開源不綁定平台、支持 SSR、有成熟團隊維護。Next.js 在紙面上滿足這些條件，但他們最終沒選。
原因之一是部署平台。Lovable 用的是 Cloudflare，Next.js 在 Cloudflare Workers 上的支持歷來是個麻煩事，而 TanStack Start 的設計從一開始就沒有平台綁定。
原因之二和 AI 代碼生成直接相關。TanStack Start 的服務器/客戶端邊界非常顯式，開發者用 createServerFn() 標註服務器函數，編譯時自動把它拆成兩個包：
服務器包：保留原始處理邏輯 客戶端包：替換成類型化的 fetch 存根
這個機制讓 AI 模型更難犯"把服務器代碼跑在瀏覽器裏"這種低級錯誤。Lovable 甚至和 TanStack 團隊合作維護了一套專用的 AI 工具規範，專門處理模型因為訓練截斷而使用過時模式的問題，比如用 Next.js 的 getServerSideProps 寫 TanStack Start 代碼。
架構改了什麼
舊架構：Cloudflare Pages 靜態託管 SPA，數據庫操作通過獨立 Edge Functions 處理。
新架構：整體遷移到 Cloudflare Workers，TanStack Start 在請求到來時在服務器側執行 React 樹，流式返回完整 HTML。
靜態內容（博客文章、落地頁）在發佈時預生成成平面 HTML，不走 SSR。動態頁面按需服務端渲染。兩種模式按路由選擇，互不干擾。
服務器密鑰的管理方式也變了。原來靠環境變量，現在作為 Cloudflare Workers 綁定注入，與代碼包完全解耦。修改密鑰不需要重新構建，立即生效。
用戶端體驗沒有變化，點擊發布，系統自動完成構建、靜態路由預生成、Worker 部署，無需手動配置任何東西。
切換之後數據怎麼樣
博客裏給出了兩個核心數據：
有機搜索流量：預渲染頁面增長了 2.9% AI 工具流量（ChatGPT、Perplexity 等）：增長了 98.5%
2.9% 看起來不大，但對於一個以 SPA 起家的平台來說，這是從無到有。SSR 之前，這塊流量接近零。
AI 工具流量將近翻倍，背後是結構化 HTML 對新一代內容入口的重要性在快速提升。Perplexity、ChatGPT 這類工具抓取頁面時，能讀到完整內容，SPA 時期同樣是讀空殼。
值得一提的是，Lovable 並沒有強制遷移老項目。已有應用繼續用原來的架構，只額外獲得了爬蟲預渲染優化。新建項目才默認用 TanStack Start，完整的遷移路徑還在推進中。
框架自己也在往外擴
Lovable 切換的同一時間，TanStack 官方也發了條動態：TanStack Start 現在支持 Rsbuild 2，和 Vite 並列。也就是說，完整的 Start 功能集延伸到了 Rspack / Webpack 生態，原本只能用 Vite 的限制被打開了。
TanStack 作者 Tanner Linsley 在轉發時說得挺直白，團隊一直以"構建與 UI 框架無關的軟件"為傲，而做到"與打包工具無關"是下一個層次的挑戰。這個表態背後是一個清晰的產品取向：不綁 UI 庫，不綁打包工具，也不綁部署平台。對應用生成平台這種需要長期押注底層框架的場景，"不被鎖死"恰恰是最值錢的東西，這也解釋了 Lovable 當初為什麼選它。
對於還在評估全棧框架的 Node.js/前端開發者，TanStack Start 的核心賣點清楚：React 生態完全兼容，SSR 原生支持，Cloudflare/Vercel/Node.js 都能部署，服務器/客戶端邊界顯式清晰。不想被平台綁死又需要全棧能力，又多了一個新選擇。