你的 CTO 在上午 9:47 轉發了 Slack 訊息：「我們能用 TYPO3 實現 Headless 嗎，還是要用 Next.js 重建？」你自 2018 年以來就在維護同一個 TYPO3 一體化系統——TypoScript 範本、Fluid 片段，以及一個擁有 40 多個自訂模組的擴充資料夾。現在有人讀了一篇關於解耦架構的部落格文章，你的路線圖剛好消失了。在過去兩年裡，我將六個企業級 TYPO3 網站遷移到 Headless 堆棧——三個透過 EXT:headless 保留了 TYPO3，三個遷移到了 Next.js + Supabase。這個決策取決於三個變數，而大多數代理商都忽略了，第一個與效能完全無關。

對我來說這不是學術性的。我已經用兩種方法啟動了生產網站，經歷了那些令人討厭的邊界情況，並看到團隊用每個堆棧要麼成功，要麼失敗——有時非常壯觀。讓我們談談我沿途學到的東西。

理解兩種方法

首先，我們到底在比較什麼？這兩個是完全不同的東西。

TYPO3 + EXT:headless（解耦）

透過這種方式，TYPO3 保留為你的 CMS，處理所有內容管理後端任務。轉變是，你用 JSON API 替換了舊式 Fluid/TypoScript 渲染。你閃閃發光的新前端？可以是 React、Vue 或任何你喜歡的，消耗那個 API。TYPO3 持續管理所有好東西，如模型、權限和工作流程。

EXT:headless 擴充？那是獲得 TYPO3 渲染過程的 VIP 後台通行證，並輸出 JSON 而不是 HTML。它不是某個附加 API——它是直接與 TYPO3 內容核心合作的真實交易。

Next.js + Supabase（完全 Headless）

另一方面，你有 Next.js 管理前端和伺服器端邏輯。Supabase（PostgreSQL、驗證、檔案儲存和即時功能的瘋狂組合）整理你的後端。這裡根本沒有 TYPO3，各位。你正在拋棄舊 CMS，尋求純粹的靈活性和現代 JS 原生設定。

EXT:headless 實際如何運作

當你在 TYPO3 上貼上 ext:headless 時，它註冊了一個改變一切的新頁面類型。不再透過 Fluid 範本傳遞內容；相反，它提供 JSON。

以下是你會得到的內容：

{
  "id": 42,
  "type": "textmedia",
  "content": {
    "header": "Welcome to our site",
    "headerLayout": 2,
    "bodytext": "<p>Some rich text content here</p>",
    "media": [
      {
        "publicUrl": "/fileadmin/images/hero.webp",
        "properties": {
          "width": 1920,
          "height": 1080,
          "alt": "Hero image"
        }
      }
    ]
  },
  "appearance": {
    "layout": "default",
    "frameClass": "default",
    "spaceAfter": "medium"
  }
}

前端然後將這些點連接到 React/Vue 元件。如果你曾經接觸過任何基於元件的 CMS，這會感覺像你最喜歡的舊毛衣。

設定 EXT:headless

典型的設定開始於：

composer require friendsoftypo3/headless

在你的 TypoScript 中：

plugin.tx_headless {
  settings {
    debug = 0
  }
}

page = PAGE
page {
  typeNum = 0
  10 = USER
  10.userFunc = FriendsOfTYPO3\Headless\ContentObject\JsonContentObject->render
}

這是有趣的部分：對於 TYPO3 中的每個自訂內容元素，你需要 JSON 序列化器。對於一個網站，比方說，有一把自訂元素？你在看幾天的工作。一個具有大量元素的龐大企業設定？做好準備——這可能需要幾週。

TYPO3 Headless 做得很好

  • 編輯器體驗保持不變。 TYPO3 的熟悉後端意味著內容編輯者無需重新培訓。
  • 保留現有內容。 你的設定不會消失。你所有的內容、翻譯和媒體？它們會保留。
  • 多語言支援搖滾樂。 TYPO3 有我見過的一些最好的語言處理。
  • 企業級功能。 從工作區到排定發佈，一切都準備好了。

EXT:headless 的陷阱

  • TYPO3 不會消失。 你需要懂 PHP 的 TYPO3 專業人士，他們並不到處都是。
  • 複雜的託管。 你在處理 PHP（TYPO3）和 Node.js（你的前端）。雙倍的樂趣，雙倍的複雜性。
  • 有限的 API 介面。 它是 JSON，不是 GraphQL。自訂意味著深入回到 TYPO3 擴充開發。
  • 預覽困擾。 整合 TYPO3 和 Next.js 的即時預覽？不適合膽小的人。

TYPO3 Headless Mode vs Next.js + Supabase：真實比較

Next.js + Supabase：完全 Headless 堆棧

版面配置

透過這個設定，Next.js 處理你的應用層，Supabase 負責所有資料庫和後端任務。

┌─────────────┐     ┌──────────────┐     ┌─────────────┐
│   Next.js   │────▶│   Supabase   │────▶│ PostgreSQL  │
│  (App Router)│     │   (BaaS)     │     │  (Database)  │
└─────────────┘     └──────────────┘     └─────────────┘

沒有 TYPO3 的內容管理

這是事情變得棘手的地方。編輯如何管理內容？

  1. 自訂管理面板。 工作量比你想象的要多。
  2. Supabase Studio。 非常適合開發者，編輯可能會恨它。
  3. 新增 CMS。 現在管理三個服務。
  4. 使用 Payload 和它自己的資料庫。 在我看來相當優雅。

這樣你就能看到，這是一個基本的使用 Supabase 的內容提取實現：

import { createClient } from '@supabase/supabase-js'

const supabase = createClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL!,
  process.env.SUPABASE_SERVICE_ROLE_KEY!
)

export async function getPage(slug: string) {
  const { data, error } = await supabase
    .from('pages')
    .select(`
      id,
      title,
      slug,
      meta_description,
      content_blocks (
        id,
        type,
        content,
        sort_order
      )
    `)
    .eq('slug', slug)
    .eq('status', 'published')
    .single()

  if (error) throw error
  return data
}

Next.js + Supabase 閃閃發光的地方

  • 極高的效能。 靜態生成、ISR、邊緣渲染——你的速度遊樂場。
  • 開發人員眾多。 JavaScript/TypeScript 人員到處都是。
  • Supabase 的行級安全。 當你想要緊密控制時真的很酷。
  • 即時功能。 像微風一樣整合實時更新。
  • 輕鬆部署。 使用 Vercel 來 Next.js 和 Supabase Cloud 來後端或自託管。

這裡的鬥爭

  • DIY CMS。 除非你在頂部放另一個 Headless CMS，否則你基本上是在建立自己的。
  • 編輯黑洞。 沒有內建工作流程。草稿狀態、排定發佈？你必須自己實現。
  • 語言管理。 多語言內容支援？你會在建立內部時流汗。
  • 媒體管理困擾。 Supabase 儲存並非為數位資產量身訂製。記住這一點。

對比分析

看看他們如何堆積：

| 功能 | TYPO3 + EXT:headless | Next.js + Supabase | |------|---------------------|--------------------|| | 編輯 UX | 優秀 | 自訂或新增 CMS | | 多語言 | 原生 | DIY 實現 | | 工作流程 | 內建 | 需要自訂建構 | | 效能 | 良好 | 優秀 | | API | 有限 | 完全控制 | | 即時 | 缺少 | 支援 | | 驗證 | 傳統 | 現代和靈活 | | 複雜性 | 高 | 中 | | 人才庫 | 稀缺 | 豐富 | | 內容遷移 | 不必要 | 完整遷移 | | 功能 | 內置 | 建構或購買 | | 設定時間 | 2-4 週 | 4-8 週 | | 成本（託管） | €150-500 | €45-200 |

效能基準

讓我們從我測試過的網站看到一些數字——公司網站、200 頁、多語言支援：

| 指標 | TYPO3 Headless + Next.js | Next.js + Supabase (SSG) | |------|--------------------------|-------------------------|| | TTFB（未快取） | 280ms | 45ms | | TTFB（CDN 快取） | 35ms | 32ms | | LCP | 1.8s | 1.2s | | CLS | 0.02 | 0.01 | | Lighthouse 分數 | 92 | 98 | | 建構時間（完整） | 4m 20s | 1m 45s | | API 回應（p95） | 180ms | 22ms |

最重要的是？雖然 Supabase 的未快取 TTFB 更好，但 CDN 快取基本上持平。設定正確時，兩者對最終使用者來說都足夠快。

TYPO3 Headless Mode vs Next.js + Supabase：真實比較 - 架構

開發者體驗和團隊考慮

深入 TYPO3

對於 Headless 專案，你仍然需要 TYPO3 專業人士。想想 PHP 序列化器、測試升級和處理相容性問題。在 2026 年，這些專家可能會花費 €80-120/小時。有些開發者對 Headless 設定不滿意——它去掉了 Fluid 範本化的樂趣。

Next.js + Supabase 俱樂部

JavaScript 開發者很豐富，但記住設計內容管理系統對每個人來說都不容易。Supabase 的開發體驗相當光滑：自動生成的 TypeScript 類型、即時訂閱和穩健的驗證助手。但所有資料建模和架構決策？這些都取決於你。

考慮這條路？我們的團隊在 Next.js 開發方面磨練了專業知識，幫助你迴避令人討厭的驚喜。

遷移策略

從傳統 TYPO3 到 TYPO3 Headless

低風險，內容保持不變。主要是前端重寫。

  1. 推出 EXT:headless
  2. 將內容元素對映到 JSON
  3. 打造 Next.js/Nuxt 前端
  4. 排序預覽整合
  5. 上線！

時間框架：對於適度規模的企業網站為 8-16 週。

從 TYPO3 到 Next.js + Supabase

抓住你的座位，這是一次完整的重建。

  1. 審核目前內容設定
  2. 草繪你的 PostgreSQL 架構
  3. 編寫遷移指令碼
  4. 移動媒體和檔案參考
  5. 建構編輯工具或整合另一個 CMS
  6. 再次建構前端
  7. 處理 URL 重定向
  8. 傳播多語言內容

時間框架：16-32 週。複雜的 Headless 開發？帶進專業人士使生活更輕鬆。

成本分析

讓我們計算中等規模企業設定的費用：200 頁、3 種語言、5 個編輯、50K 月訪問量。

TYPO3 Headless — 第一年成本

項目 成本
TYPO3 託管（託管） €3,600/年
Next.js 託管（Vercel Pro） €240/年
前端開發 €25,000-45,000
EXT:headless 整合 €8,000-15,000
第一年總計 €36,840-63,840
持續年度 €5,000-8,000

Next.js + Supabase — 第一年成本

項目 成本
Supabase Pro €300/年
Vercel Pro €240/年
新增 CMS（如需要） €0-3,600/年
內容遷移 €10,000-20,000
前端 + 後端開發 €40,000-70,000
編輯工具 €10,000-25,000
第一年總計 €60,540-119,140
持續年度 €2,000-6,000

完全 Headless 前期成本龐大，但由於你拋棄了 TYPO3 託管，月度費用會下降。只是不要低估在頂部額外的 CMS 建構。

何時選擇哪個

TYPO3 + EXT:headless

  • 堅持傳統內容和既定工作流程。
  • 保留熟悉的編輯設定和豐富功能。
  • 受益於複雜的原生多語言支援。
  • 保留 TYPO3 開發者。

Next.js + Supabase

  • 從頭開始時。
  • 應用程式需要充足的互動功能。
  • 你的開發團隊已經是 JavaScript 焦點。
  • 保持高效能是關鍵焦點。
  • 習慣新增 Headless CMS。

考慮第三個角度

也許混合它也穿過你的腦海？Next.js、Headless CMS 加上 Supabase 用於應用資料可以結合最好的。它提供成熟的編輯工具，沒有 TYPO3 包袱。如果你也在考慮針對輕量級內容豐富網站的 Astro 開發選項，那也值得一看。

想談談你的具體需求？我們在這裡幫助評估什麼對你的獨特情況有意義——聯絡我們，我們承諾誠實評估，即使是「堅持你所知道的」。

常見問題

TYPO3 EXT:headless 在 2026 年可以在生產中使用嗎？ 是的，完全沒有問題。EXT:headless 自版本 3.x 以來一直很穩定，並得到積極支援。版本 4.x 涵蓋 TYPO3 v12 和 v13，具有穩健的內容序列化、功能表生成和表格處理。許多大型企業網站在生產設定中執行它，包括德國和奧地利的政府和銀行等部門。

我能為 TYPO3 Headless 前端使用 Next.js 嗎？ 當然可以，這是一個經典的組合。你將利用 Next.js App Router 與伺服器元件從 TYPO3 的 JSON API 收集資訊。預覽整合是最棘手的部分：設定草稿模式並引導 TYPO3 透過預覽 URL 呼叫它。幸運的是，社區的有用文件會指導你完成 Next.js 配對。

Supabase 與 TYPO3 的資料庫設定相比如何？ 哦，這些是蘋果和橙子。TYPO3 在 Doctrine DBAL 上執行，具有由 TCA 管理的更嚴格的架構。Supabase 提供了那種甜蜜的 PostgreSQL 自由度，具有行級安全。Supabase 提供靈活而強大的查詢能力，但 TYPO3 經過精心結構化，以防止編輯可能無意中引入的錯誤。這都是關於控制與安全。

使用 Headless TYPO3 的 SEO 問題？處理中繼標籤和結構化資料？ EXT:headless 確實序列化頁面屬性，如中繼標籤和開放圖形資料。你的前端需要將它們呈現為 HTML 標籤。使用 Next.js 的 Metadata API 在佈局中。只要你的 TYPO3 設定牢固，SEO 資料應該會跟著。整合擴充如 EXT:yoast_seo，它將與 Headless 配置進行良好配合。

Supabase 是否達到企業級內容交付水準？ 當然可以。Supabase Cloud 在 AWS 上執行，在專業計劃上提供 99.9% 的正常運行時間，並提升到團隊計劃上的 99.95%（檢查 2026 年費率）。用於 CDN 快取（Vercel 的邊緣網路、Cloudflare），Supabase 主要確保寫入和即時功能可靠性。對於關鍵企業使用，自託管 Supabase 以獲得最大控制。

我們如何不用 TYPO3 處理影像處理？ TYPO3 原生處理影像——裁剪、調整大小、格式翻轉。沒有它，建立你的影像工作流程。2026 年頂級競爭者是：Next.js 影像最佳化（內建、Vercel 支援）、Cloudinary（免費開始，嚴肅用途需要付費計劃）或 imgix（起價 €100+/月）。Supabase 儲存處理原件，但不轉換。

我們能從 TYPO3 Headless 遞增遷移到完全 Headless 嗎？ 絕對可以，想想這是一個順利的計劃。從 Headless TYPO3 開始，隔離前端。漸漸地將內容從 TYPO3 轉移到 Supabase 或你選擇的 CMS——從更簡單的類型開始。在此期間，你的 Next.js 前端使用來自兩個來源的資料。

TYPO3 團隊轉向 Next.js + Supabase 的學習曲線是什麼？ 一個現實的加速是大約三到六個月。也就是說，挑戰不是 JavaScript 或 TypeScript——這是範例轉變。TYPO3 開發者習慣於框架引導內容結構、快取和路由。在 Next.js + Supabase 模型中，那些呼叫都是你的。這既令人欣喜又起初令人困惑。與經驗豐富的 Next.js 專業人士配對程式設計使這個飛躍更平順。