Lovable 的限制：何時應該改寫為 Next.js

我已經看到這個模式發生過十多次。一位創辦人在週末用 Lovable 建立了一個 SaaS 原型。看起來很棒。投資者印象深刻。用戶註冊。然後現實來臨：Google 沒有索引市場頁面、新增團隊工作區時驗證流程崩潰、你的 Supabase 查詢開始在租戶之間衝突，你意識到自己在與工具對抗，而不是在構建產品。

Lovable 對於它所做的事情確實令人印象深刻。但有一個上限，如果你在構建真實的 SaaS 產品，你會撞到它。本文詳細分析了 Lovable 的不足之處、何時應該計畫遷移到自訂 Next.js，以及如何進行重寫而不失理智。

理解 Lovable 的架構

在我們討論限制之前，讓我們明確說明 Lovable 實際上產生的是什麼。在引擎蓋下，Lovable 產生一個 Vite + React 應用程式，具有客戶端渲染 (CSR)。就這樣。沒有伺服器端渲染。沒有靜態網站生成。沒有增量靜態再生。純 CSR。

這不是秘密 -- Lovable 自己的 FAQ on rendering 對此表示承認。他們推薦預渲染作為 SEO 的解決方法，他們坦誠 SSR 在「Lovable 的目前設置中更困難」。

生成的程式碼通常使用：

React Router 用於客戶端導航
Supabase 用於驗證和資料庫
Tailwind CSS 用於樣式
shadcn/ui 元件

對於內部工具、驗證後的儀表板或快速原型？這個堆疊完全沒問題。當你的產品要求超出單頁應用程式可以處理的範圍時，問題就開始了。

Lovable 做得好的地方

公平地說。Lovable 在以下方面表現出色：

原型製作速度：你可以在幾小時內獲得工作中的 UI，而不是幾週
設計品質：生成的介面看起來開箱即用就很精緻
Supabase 整合：基本的驗證流程和 CRUD 操作可快速工作
元件品質：它生成的 shadcn/ui 元件是生產級別的

問題不在品質 -- 而在範圍。Lovable 針對盡快達到 v0.1 進行最佳化。它不針對達到 v2.0 進行最佳化。

SEO 問題：CSR 對公共頁面來說是死胡同

這是最直接和最痛苦的限制，也是讓創辦人措手不及的原因。如果你的 SaaS 有任何公開頁面 -- 市場網站、部落格、文件、定價頁面、應該可索引的使用者生成內容 -- Lovable 的 CSR 架構主動在與你作對。

這是當爬蟲程式擊中 Lovable 產生的頁面時發生的情況：

<!-- Googlebot 看到的內容（有時） -->
<!DOCTYPE html>
<html>
  <head>
    <title>My SaaS App</title>
  </head>
  <body>
    <div id="root"></div>
    <script type="module" src="/assets/index-abc123.js"></script>
  </body>
</html>

那個空的 <div id="root"> 就大多數爬蟲程式而言是你的整個頁面內容。Google 的 Web Rendering Service (WRS) 可以執行 JavaScript 並渲染 CSR 內容，但這有真實的問題：

不保證。 Google 可能會或可能不會渲染你的 JavaScript。當它這樣做時，從發現到渲染可能有數小時到數天的延遲。
其他所有爬蟲程式都失敗了。 LLM 爬蟲程式（GPTBot、ClaudeBot、PerplexityBot）、社群媒體展開程式（Facebook、LinkedIn、Twitter/X、Slack、Discord）、Bing 的渲染器（不如 Google 的可靠）-- 這些都不能可靠地執行 JavaScript。
社群分享被破壞。 在 LinkedIn 上分享 Lovable 頁面，你會得到空白的預覽卡。這對你試圖發展的產品來說是一個可怕的第一印象。
AI 搜尋可見度為零。 這在 2026 年變得越來越重要。如果 Perplexity、ChatGPT 搜尋或 Claude 看不到你的內容，你在 AI 產生的答案中就不存在。

正如 Nati Elimelech 在一篇廣為流傳的 LinkedIn 貼文中指出的：「Lovable 的架構（Vite + React CSR）從根本上與現代爬蟲程式要求不相容。」

Lovable 的預渲染解決方法

Lovable 確實提供預渲染作為解決方法。這在建置時將你的動態 React 應用程式轉換為靜態 HTML。它適用於真正靜態的頁面 -- 簡單的登陸頁面、關於頁面。但它對以下情況會崩潰：

經常更新的部落格內容（你需要在每次發布時重新建置）
動態產品頁面（例如，範本庫、市場清單）
使用者生成的公開個人資料
帶有版本控制的文件
任何內容每天更改超過一次的頁面

將其與 Next.js 進行比較，你可以獲得 每條路由的渲染控制：

// 在建置時進行靜態生成（例如部落格文章）
export async function generateStaticParams() {
  const posts = await getAllPosts();
  return posts.map((post) => ({ slug: post.slug }));
}

// 在每個請求上進行伺服器端渲染（例如使用者個人資料）
export const dynamic = 'force-dynamic';

// 增量靜態再生（每 60 秒重新驗證一次）
export const revalidate = 60;

這種每條路由的靈活性是 Lovable 無法提供的。當我們為客戶構建 Next.js 專案時，這種細粒度的渲染控制通常是他們從 CSR 專用工具遷移的單一最大原因。

超越基本登入的驗證複雜性

Lovable 的 Supabase 整合處理基礎知識：電子郵件/密碼註冊、魔法連結、也許是 Google OAuth。這對原型就足夠了。對於生產 SaaS 來說還不夠。

以下是驗證變得複雜而 Lovable 無法跟上的地方：

基於角色的存取控制 (RBAC)

真實的 SaaS 應用程式需要角色。所有者、管理員、成員、檢視者層級至少。當你在 Lovable 中時，實現 RBAC 意味著：

手動撰寫自訂 Supabase RLS（行級安全性）政策
在用戶端上管理角色狀態（這對於授權決策本質上不安全）
在 React 元件中構建你自己的類似中間件的邏輯

在 Next.js 中，你在伺服器級別處理授權，然後再發送任何內容：

// middleware.ts -- 在頁面呈現之前執行
import { NextResponse } from 'next/server';
import { createServerClient } from '@supabase/ssr';

export async function middleware(request) {
  const supabase = createServerClient(/* config */);
  const { data: { user } } = await supabase.auth.getUser();
  
  if (!user) {
    return NextResponse.redirect(new URL('/login', request.url));
  }

  const { data: membership } = await supabase
    .from('team_members')
    .select('role')
    .eq('user_id', user.id)
    .eq('team_id', extractTeamId(request.url))
    .single();

  if (membership?.role !== 'admin' && request.nextUrl.pathname.includes('/settings')) {
    return NextResponse.redirect(new URL('/dashboard', request.url));
  }

  return NextResponse.next();
}

這在伺服器上執行。未授權的使用者永遠看不到設定頁面、永遠不會收到 HTML、永遠不會得到 JavaScript 套件。在 CSR 應用程式中，你在運送程式碼並用客戶端檢查隱藏它 -- 任何有動機的使用者都可以繞過。

跨子域的工作階段管理

如果你的 SaaS 使用子域名（如 acme.yourapp.com），你需要跨子域名工作的 Cookie、處理邊界情況的令牌重新整理邏輯，以及不在租戶之間洩漏的工作階段驗證。Lovable 不為你提供伺服器端基礎設施來處理此問題。你最終會拼湊出在生產環境中崩潰的解決方法。

企業 SSO (SAML/OIDC)

一旦你向擁有超過 50 名員工的公司銷售，有人會要求 SAML 或 OIDC 整合。這需要伺服器端回呼處理、令牌交換和安全的工作階段建立。這從根本上來說是一個伺服器端流程。試圖在 CSR 專用應用程式中實現它是與重力對抗。

Lovable AI Builder Limitations: When to Rewrite in Next.js - architecture

多租戶資料：Lovable 無法解決的地方

多租戶是 SaaS 的決定性架構挑戰。每個請求都需要限定在正確的組織。每個查詢都需要按租戶篩選。每個資料片段都需要隔離保證。

Lovable 為你提供 Supabase，它可以通過 RLS 政策處理多租戶。但應用程式級別的模式 -- 路由、上下文、資料擷取 -- 完全取決於你，Lovable 的 AI 不產生多租戶感知程式碼。

兩個模式

模式	範例	優點	缺點
路徑型	`app.com/[team]/dashboard`	簡單託管，無 DNS 設定	客戶品牌化程度較低
子域型	`team.app.com`	更好的白標、更乾淨的 URL	需要萬用字元 SSL、DNS 設定、中間件路由

Next.js 以本機方式支援兩者。App Router 的動態段優雅地處理路徑型路由：

app/
  [teamSlug]/
    dashboard/
      page.tsx
    settings/
      page.tsx
    billing/
      page.tsx

對於子域型路由，Next.js 中間件可以提取子域名並在任何頁面程式碼執行之前解決租戶：

// middleware.ts
export function middleware(request) {
  const hostname = request.headers.get('host');
  const subdomain = hostname?.split('.')[0];
  
  // 重寫 URL 以包含租戶上下文
  if (subdomain && subdomain !== 'www' && subdomain !== 'app') {
    return NextResponse.rewrite(
      new URL(`/${subdomain}${request.nextUrl.pathname}`, request.url)
    );
  }
}

在 Lovable 中，你會用 React Router 和自訂掛鉤連接這個，進行客戶端擷取呼叫來解決租戶，並處理加載狀態期間錯誤租戶內容的閃爍。我見過這種情況發生。並不漂亮。

資料隔離顧慮

最可怕的多租戶漏洞是資料洩漏 -- 向租戶 B 顯示租戶 A 的資料。在伺服器呈現架構中，你可以在發送回應之前在資料層強制執行租戶範圍。在 CSR 中，你相信客戶端程式碼將正確的租戶 ID 傳遞給你的 API，希望你的 RLS 政策能解決其他一切。

RLS 是你的安全網，而不是你的主要防禦。你的主要防禦應該是在每個請求上驗證租戶上下文的伺服器端中間件。Lovable 不為你提供那一層。

超越啟動程式 SaaS 的擴展

有一組問題在你有真實用戶、真實資料和真實業務需求之前不會出現。Lovable 的產生程式碼不是為這些情況設計的。

規模性能

Lovable 應用程式以 JavaScript 套件的形式運送你的整個應用程式。當你的應用程式增長時，該套件也會增長。React Router 將所有內容加載到用戶端的記憶體中。用戶在較慢的連線或較舊的設備上感受到這一點。

Next.js 在路由級別提供自動程式碼分割。導航到 /dashboard 並且你只加載儀表板程式碼。導航到 /settings 並且只加載設定程式碼。這是自動的 -- 你無需設定它。

背景工作和伺服器邏輯

真實的 SaaS 應用程式需要：

Webhook 處理程式（Stripe、SendGrid、第三方整合）
排定的工作（計費週期、報告生成、資料清理）
帶有伺服器端範本的電子郵件發送
PDF 生成
檔案處理

在 CSR 專用應用程式中這些都不可能。你需要一個單獨的後端。使用 Next.js，你可以直接處理 webhook 和伺服器邏輯：

// app/api/webhooks/stripe/route.ts
export async function POST(request: Request) {
  const body = await request.text();
  const sig = request.headers.get('stripe-signature');
  
  const event = stripe.webhooks.constructEvent(body, sig, webhookSecret);
  
  switch (event.type) {
    case 'customer.subscription.updated':
      await updateSubscription(event.data.object);
      break;
    case 'invoice.payment_failed':
      await handleFailedPayment(event.data.object);
      break;
  }
  
  return Response.json({ received: true });
}

這是一個運行伺服器端程式碼的真實 API 端點，在與你的前端相同的程式碼庫中。沒有單獨的 Express 伺服器。沒有單獨的部署。

測試和 CI/CD

Lovable 產生的專案沒有附帶測試基礎設施。沒有單位測試、沒有整合測試、沒有端到端測試。對於原型來說，這很好。對於生產 SaaS 處理客戶付款和敏感資料，這是一個責任。

Next.js 專案與 Jest、Vitest、Playwright 和 Cypress 自然整合。你可以獨立地測試伺服器元件、API 路由和中間件。

何時遷移：決策框架

不是每個 Lovable 專案都需要重寫。這是一個實用的框架：

留在 Lovable 上，如果：

你處於產品市場契合度前，仍在驗證中
你的應用程式完全在驗證後（不需要 SEO 的公共頁面）
你有單租戶模型（一個用戶、一個帳戶）
你是內部工具或管理面板
你的團隊沒有開發人員資源

計畫遷移，如果：

你需要公開頁面的有機搜尋流量
你在新增團隊/組織工作區
企業客戶要求 SSO
你的 Supabase RLS 政策變成義大利麵
你需要伺服器端整合（webhook、付款處理）
頁面加載時間隨著你的應用程式增長而上升
你花在與 Lovable 對抗上的時間比構建功能還多

立即遷移，如果：

你已經有過（或幾乎有過）多租戶資料洩漏
Google Search Console 顯示重要頁面上的索引失敗
因為 SSO/安全需求，你失去了交易
你的用戶端套件超過 500KB gzip

如何進行重寫

最糟糕的事情是試圖進行大爆炸重寫，在其中從頭重新構建所有內容並翻轉開關。這就是重寫所消亡的地方。

陌生人樹莓圖案

最聰明的方法是增量。將你的 Next.js 應用程式與你的 Lovable 應用程式並行部署，並逐個遷移路由。

從公開頁面開始。 將你的市場網站、部落格和文件遷移到具有適當 SSR/SSG 的 Next.js。這為你帶來即時 SEO 贏家。
移動驗證層。 在 Next.js 中間件中實現你的驗證流程。這是最難的部分 -- 盡早進行。
逐功能遷移。 從最簡單的頁面開始，朝向最複雜的頁面工作。
重新使用你的元件。 Lovable 產生 React 元件。其中大多數都可以在 Next.js 中以最少的更改工作 -- 主要是移除 React Router 依賴項並轉換為基於檔案的路由。

甚至有一個 CLI 工具（NextLovable）可以自動化部分結構轉換：

npx @nextlovable/cli convert ./src/components/ -f app-router

它處理從 Lovable 的平面元件目錄到 Next.js App Router 的嵌套佈局模式的檔案結構轉換。它不會處理你的業務邏輯，但它可以節省數小時乏味的檔案移動。

什麼要預算

對於中等複雜度 SaaS（10-20 頁、驗證、基本多租戶）的現實遷移時間表：

階段	時間表	工作量
公開頁面 + SEO	1-2 週	低
驗證 + 中間件	2-3 週	高
儀表板遷移	3-4 週	中
API 路由 + webhook	1-2 週	中
測試 + QA	1-2 週	中
總計	8-13 週	--

如果你寧願不花三個月在遷移上，那正是我們處理的專案類型。我們已經做了足夠多的這些，知道地雷在哪裡。

Lovable 對比自訂 Next.js：並排比較

功能	Lovable（Vite + React CSR）	自訂 Next.js
原型製作時間	小時	幾天到幾週
SSR / SSG / ISR	❌ 無（僅預渲染）	✅ 完整支援，每條路由
公開頁面的 SEO	⚠️ 差（取決於 Google 的 JS 渲染）	✅ 優秀
AI 搜尋可見度	❌ 對 LLM 爬蟲程式不可見	✅ 完全可見
社群預覽卡	❌ 破壞的	✅ 動態 OG 圖像
多租戶	⚠️ 手動、客戶端專用	✅ 中間件 + 伺服器端
驗證（基本）	✅ Supabase 整合	✅ 多個提供者
驗證（企業 SSO）	❌ 無伺服器端支援	✅ SAML/OIDC 支援
API 路由	❌ 需要單獨後端	✅ 內置
程式碼分割	⚠️ 手動	✅ 每條路由自動
測試基礎設施	❌ 無產生	✅ 完整生態系統
部署靈活性	Lovable 託管或 Netlify/Vercel（靜態）	Vercel、AWS、Docker、自託管
規模成本	$20-50/mo (Lovable) + Supabase	託管變化 ($0-200+/mo)

常見問題

我可以為我的 SaaS 市場網站使用 Lovable，為應用程式使用 Next.js 嗎？ 你可以，但它會創建維護開銷。你會有兩個程式碼庫、兩個部署管道，可能會有不一致的設計。更好的方法是在 Next.js 中構建所有內容 -- 為市場頁面使用靜態生成，為應用程式使用伺服器元件。如果你已經在 Lovable 上，首先開始只遷移公開頁面到 Next.js，直到你準備好進行完整遷移時保持應用程式在 Lovable 上。

Lovable 的預渲染可以解決 SEO 問題嗎？ 部分。預渲染在建置時產生靜態 HTML，爬蟲程式可以讀取。它適用於很少更改的頁面 -- 關於頁面、定價頁面。但它不適用於經常更新的部落格文章、使用者生成的內容或市場清單等動態內容。你需要在內容更改時觸發重新構建，這變得不切實際。Next.js 的 ISR（增量靜態再生）通過按計劃或按需重新驗證頁面優雅地處理這個問題。

Lovable 到 Next.js 的遷移通常花費多少？ 對於簡單的原型（5-10 頁、基本驗證），預期 2-4 週的開發人員時間。對於具有多租戶、自訂驗證流程和 API 整合的中等複雜度 SaaS，預算 8-13 週。以機構費率計算，這大約是 $15,000-$50,000，具體取決於複雜程度。你可以查看我們的定價，或聯繫我們，以根據你的實際程式碼庫進行範圍估計。

是否可以從 Lovable 逐步遷移到 Next.js？ 完全可以，這是推薦的方法。使用陌生人樹莓圖案：將 Next.js 與你的 Lovable 應用程式並行部署，逐個遷移路由，從公開頁面開始，並使用反向代理或 DNS 路由從同一域名為兩個應用程式提供服務。NextLovable 的 CLI 可以自動化部分結構轉換。

對於公開頁面使用 Astro 而不是 Next.js 如何？ Astro 對於內容豐富、互動性最少的網站非常好。如果你的公開頁面主要是靜態市場內容，你的應用程式是一個單獨的 SPA，Astro 是一個很好的選擇。但如果你想要一個統一的程式碼庫用於市場頁面和動態應用程式，Next.js 是更實用的選擇。我們根據用戶端的需求使用兩者構建 -- 這取決於你的公開頁面需要多少互動性。

我的 Lovable React 元件會在 Next.js 中工作嗎？ 大多數都會以最少的修改工作。主要的變化是：移除 React Router 匯入並改為使用 Next.js Link 和 useRouter、為使用 useState 或 useEffect 等掛鉤的元件新增 'use client' 指令、取代任何 Lovable 特定的公用程式。元件邏輯和樣式（Tailwind 類、shadcn/ui 元件）直接轉移。

如果我不是開發人員 -- 我仍然可以離開 Lovable 嗎？ 是的，但你需要開發人員幫助。遷移是一個技術專案。你可以聘請自由接案 Next.js 開發人員、使用無頭開發機構，如我們，或使用 NextLovable CLI 來獲得領先優勢，然後為複雜部分帶來幫助。好消息是 Lovable 的產生程式碼很乾淨且結構良好，這使得開發人員比大多數 AI 產生的程式碼庫更容易工作。

2026 年 Lovable 仍然是正確的選擇？ Lovable 非常適合內部工具、管理面板、驗證後面的儀表板、向投資者展示的 MVP，以及用於使用者測試的快速原型。如果你的團隊外沒有人需要通過搜尋找到你的應用程式，你不需要複雜的驗證或多租戶，Lovable 可以帶你走得出人意料地遠。關鍵是對自己何時已經超出規模是誠實的 -- 並且不要等到技術債務壓倒你才開始計畫遷移。

Lovable AI 建構器的局限性：何時改用 Next.js 重寫

Lovable 的限制：何時應該改寫為 Next.js

目錄

理解 Lovable 的架構

Lovable 做得好的地方

SEO 問題：CSR 對公共頁面來說是死胡同

Lovable 的預渲染解決方法

超越基本登入的驗證複雜性

基於角色的存取控制 (RBAC)

跨子域的工作階段管理

企業 SSO (SAML/OIDC)

多租戶資料：Lovable 無法解決的地方

兩個模式

資料隔離顧慮

超越啟動程式 SaaS 的擴展

規模性能

背景工作和伺服器邏輯

測試和 CI/CD

何時遷移：決策框架

如何進行重寫

陌生人樹莓圖案

什麼要預算

Lovable 對比自訂 Next.js：並排比較

常見問題

Let's build
something together.

Lovable 的限制：何時應該改寫為 Next.js

目錄

理解 Lovable 的架構

Lovable 做得好的地方

SEO 問題：CSR 對公共頁面來說是死胡同

Lovable 的預渲染解決方法

超越基本登入的驗證複雜性

基於角色的存取控制 (RBAC)

跨子域的工作階段管理

企業 SSO (SAML/OIDC)

多租戶資料：Lovable 無法解決的地方

兩個模式

資料隔離顧慮

超越啟動程式 SaaS 的擴展

規模性能

背景工作和伺服器邏輯

測試和 CI/CD

何時遷移：決策框架

如何進行重寫

陌生人樹莓圖案

什麼要預算

Lovable 對比自訂 Next.js：並排比較

常見問題

Let's build something together.

Let's build
something together.