TYPO3 無頭模式 vs Next.js + Supabase：真實比較
這對我而言不僅僅是學術性的。我已經用兩種方法啟動了生產網站，經歷了那些令人討厭的邊界案例，並看到團隊要麼因為每種堆棧而成功，要麼有時還會壯觀地失敗。讓我們談談我一路上學到的東西。
理解兩種方法
首先，我們在比較什麼？這兩者完全是不同的東西。
TYPO3 + EXT:headless（解耦）
使用這種方法，TYPO3 仍然是你的 CMS，處理所有內容管理後端任務。與眾不同的是，你用 JSON API 替換了舊式的 Fluid/TypoScript 渲染。你閃亮的新前端？它可以是 React、Vue，或任何你想要的，消費那個 API。TYPO3 繼續管理所有的好東西，比如模型、權限和工作流。
EXT:headless 擴展？那是進入 TYPO3 渲染過程並輸出 JSON 而不是 HTML 的 VIP 後台通行證。它不是某個附加 API——它是真正的交易，直接與 TYPO3 的內容核心一起工作。
Next.js + Supabase（完全無頭）
另一方面，你有 Next.js 管理你的前端和服務器端邏輯。Supabase（PostgreSQL、身份驗證、文件存儲和實時功能的奇妙組合）處理你的後端。這裡完全沒有 TYPO3，夥計們。你正在用純粹的靈活性和現代 JS 原生設置拋棄舊 CMS。
EXT:headless 實際上是如何工作的
當你把 ext:headless 套到 TYPO3 上時，它註冊了一個改變一切的新頁面類型。不再通過 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 無頭模式表現良好的地方
- 編輯體驗保持不變。 TYPO3 熟悉的後端意味著內容編輯無需重新培訓。
- 保留現有內容。 你的設置不會消失。所有你的內容、翻譯和媒體？它們都留下來。
- 多語言支持非常好。 TYPO3 擁有我所見過的最好的語言處理。
- 企業級功能。 從工作區到計劃發布的一切都已準備就緒。
EXT:headless 的問題
- TYPO3 不會消失。 你仍然需要了解 TYPO3 的 PHP 人才，而他們不是隨處可得。
- 複雜的主機託管。 你在處理 PHP（TYPO3）和 Node.js（你的前端）。雙倍的樂趣，雙倍的複雜性。
- 有限的 API 接口。 它是 JSON，不是 GraphQL。自定義意味著潛入 TYPO3 擴展開發。
- 預覽麻煩。 整合 TYPO3 和 Next.js 的實時預覽？這不是為膽小的人設計的。
Next.js + Supabase：完全無頭堆棧
架構
使用這個設置，Next.js 負責你的應用層，Supabase 衝過去處理所有數據庫和後端任務。
┌─────────────┐ ┌──────────────┐ ┌─────────────┐
│ Next.js │────▶│ Supabase │────▶│ PostgreSQL │
│ (App Router)│ │ (BaaS) │ │ (Database) │
└─────────────┘ └──────────────┘ └─────────────┘
沒有 TYPO3 的內容管理
這是事情變得棘手的地方。編輯如何管理內容？
- 自定義管理面板。 比你想象的要多得多的工作。
- Supabase Studio。 對開發者很好，編輯可能會討厭它。
- 添加一個 CMS。 現在管理三項服務。
- 使用自己的數據庫的 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 的行級安全。 當你想要緊密控制時真的很酷。
- 實時功能。 集成即時更新像輕鬆一樣。
- 簡單部署。 為 Next.js 使用 Vercel，為後端使用 Supabase Cloud 或自託管。
這裡的困難
- DIY CMS。 除非你把另一個無頭 CMS 扔進去，否則你基本上是自己製造的。
- 編輯黑洞。 沒有內置的工作流。草稿狀態、計劃發布？你得自己實現。
- 語言管理。 多語言內容支持？你將花力氣自己構建它。
- 媒體管理困擾。 Supabase 存儲不是為數字資產量身定制的。記住這一點。
頭對頭對比
看看他們如何堆疊：
| 功能 | TYPO3 + EXT:headless | Next.js + Supabase |
|---|---|---|
| 編輯 UX | 優秀 | 自定義或添加的 CMS |
| 多語言 | 原生 | DIY 實現 |
| 工作流 | 內置 | 需要自定義構建 |
| 性能 | 良好 | 優秀 |
| API | 有限 | 完全控制 |
| 實時 | 缺少 | 支持 |
| 身份驗證 | 遺留 | 現代和靈活 |
| 複雜性 | 高 | 中等 |
| 人才庫 | 稀缺 | 豐富 |
| 內容遷移 | 不必要 | 完全遷移 |
| 功能 | 內置 | 構建或購買 |
| 設置時間 | 2-4 週 | 4-8 週 |
| 成本（主機託管） | €150-500 | €45-200 |
性能基準
讓我們看看我測試過的一個網站的一些數字——企業網站、200 頁、多語言支持：
| 指標 | TYPO3 無頭 + 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 |
底線？雖然未緩存 TTFB 在 Supabase 中更好，但 CDN 緩存基本上使遊樂場平整。兩者在設置正確時都足夠快，適合終端用戶。
開發者體驗和團隊考慮
深入了解 TYPO3
你仍然需要 TYPO3 專業人士來進行無頭項目。考慮 PHP 序列化程序、測試升級和處理兼容性問題。在 2025 年，這些專家可能要花你 €80-120/小時。一些開發者對無頭設置沒有感到興奮——它奪去了 Fluid 模板的樂趣。
Next.js + Supabase 俱樂部
JavaScript 開發者很多，但請記住為每個人設計內容管理系統並不容易。Supabase 的開發體驗相當光滑：自動生成的 TypeScript 類型、實時訂閱和堅實的身份驗證幫助程序。但所有數據建模和架構決策？那些都由你負責。
在考慮這條路線？我們的團隊在 Next.js 開發 中磨練了專業知識，以幫助你避免令人討厭的驚喜。
遷移策略
從傳統 TYPO3 到 TYPO3 無頭
風險較低，內容保持完整。主要是前端重寫。
- 推出 EXT:headless
- 將內容元素映射到 JSON
- 製作 Next.js/Nuxt 前端
- 排序預覽集成
- 上線！
時間表：對於一個相當規模的企業網站為 8-16 週。
從 TYPO3 到 Next.js + Supabase
抓緊，這是一次完全重建。
- 審計當前內容設置
- 草擬你的 PostgreSQL 架構
- 編寫遷移腳本
- 移動媒體和文件參考
- 構建編輯工具或集成另一個 CMS
- 再次為前端構建
- 處理 URL 重定向
- 傳播多語言內容
時間表：16-32 週。複雜的無頭開發？帶來專業人士使生活更輕鬆。
成本分析
讓我們為一個中等企業設置計算：200 頁、3 種語言、5 個編輯、月訪問量 50K。
TYPO3 無頭——第 1 年成本
| 項目 | 成本 |
|---|---|
| TYPO3 主機託管（託管） | €3,600/年 |
| Next.js 主機託管（Vercel Pro） | €240/年 |
| 前端開發 | €25,000-45,000 |
| EXT:headless 集成 | €8,000-15,000 |
| 第 1 年總計 | €36,840-63,840 |
| 持續年度 | €5,000-8,000 |
Next.js + Supabase——第 1 年成本
| 項目 | 成本 |
|---|---|
| Supabase Pro | €300/年 |
| Vercel Pro | €240/年 |
| 添加 CMS（如果需要） | €0-3,600/年 |
| 內容遷移 | €10,000-20,000 |
| 前端 + 後端開發 | €40,000-70,000 |
| 編輯工具 | €10,000-25,000 |
| 第 1 年總計 | €60,540-119,140 |
| 持續年度 | €2,000-6,000 |
完全無頭成本預先很大，但由於你放棄 TYPO3 主機託管，可以降低月度費用。只是不要低估在頂部構建額外 CMS 的費用。
何時選擇哪一個
TYPO3 + EXT:headless
- 堅持遺留內容和既定工作流。
- 保留熟悉的編輯設置和豐富的功能。
- 從複雜的原生多語言支持中受益。
- 保留 TYPO3 開發者。
Next.js + Supabase
- 從頭開始時。
- 應用程序需要大量交互功能。
- 你的開發團隊已經以 JavaScript 為中心。
- 保持性能一流是一個關鍵焦點。
- 可以舒適地添加一個無頭 CMS。
考慮第三個角度
也許混合它做交叉了你的想法？Next.js、一個無頭 CMS 加上 Supabase 應用數據可以結合最好的。它提供全面的編輯工具而沒有 TYPO3 的負擔。如果你也在考慮 Astro 開發 之類的輕量級內容豐富網站選項，那值得一看。
想談談你的具體需求？我們在這裡幫助評估什麼對你的獨特情況有意義——聯絡我們，我們保證誠實評估，即使是「堅持你所知道的」。
常見問題
2025 年 TYPO3 EXT:headless 生產就緒嗎？ 是的，絕對。EXT:headless 自版本 3.x 以來一直很穩定，並得到積極支持。版本 4.x 涵蓋 TYPO3 v12 和 v13，具有堅實的內容序列化、菜單生成和表單處理。大量的大型企業網站在生產設置中運行它，包括德國和奧地利的政府和銀行部門。
我可以為 TYPO3 無頭前端使用 Next.js 嗎？ 當然可以，這是經典組合。你將利用 Next.js App Router 與服務器組件從 TYPO3 的 JSON API 中收集信息。預覽集成是最棘手的部分：設置草稿模式並指導 TYPO3 通過預覽 URL 調用它。幸運的是，社區有幫助文檔指導你通過 Next.js 配對。
Supabase 與 TYPO3 的數據庫設置相比如何？ 哦，這些是蘋果和橙子。TYPO3 在 Doctrine DBAL 上運行，使用 TCA 管理的更嚴格的架構。Supabase 提供那甜蜜的 PostgreSQL 自由與行級安全。Supabase 提供靈活和強大的查詢能力，但 TYPO3 經過仔細結構化以防止編輯可能意外引入的錯誤。這一切都是控制與安全的事情。
無頭 TYPO3 的 SEO 顧慮？處理元標籤和結構化數據？
EXT:headless 確實序列化了頁面屬性，如元標籤和 Open Graph 數據。你的前端需要將它們渲染為 HTML 標籤。在佈局中使用 Next.js 的元數據 API。只要你的 TYPO3 設置可靠，SEO 數據應該跟隨套件。集成像 EXT:yoast_seo 這樣的擴展，它將與無頭配置很好地配合。
Supabase 能達到企業級內容交付嗎？ 當然可以。Supabase Cloud 在 AWS 上運行，在 Pro 計劃中提供 99.9% 正常運行時間，並在 Team 計劃上增加到 99.95%（檢查 2025 年費率）。對於 CDN 緩存（Vercel 邊緣網絡、Cloudflare），Supabase 主要確保寫入和實時功能可靠性。對於關鍵企業使用，自託管 Supabase 以獲得最大控制。
沒有 TYPO3 我們如何應對圖像處理？ TYPO3 本地處理圖像——裁剪、調整大小、格式翻轉。沒有它，設置你的圖像工作流。2025 年的頂級競爭者是：Next.js 圖像優化（內置、Vercel 支持）、Cloudinary（免費啟動、認真使用需要付費計劃）或 imgix（起價 €100+/月）。Supabase 存儲處理原件但不轉換。
我們可以從 TYPO3 無頭到完全無頭漸進遷移嗎？ 絕對，想到它像一個光滑的計劃。從無頭 TYPO3 開始，隔離你的前端。緩慢將內容從 TYPO3 過渡到 Supabase 或你選擇的 CMS——從簡單的類型開始。在階段期間，你的 Next.js 前端從兩個源操作數據。
對於從 TYPO3 過渡到 Next.js + Supabase 的 TYPO3 團隊，學習曲線像什麼？ 現實的加速時間大約是三到六個月。也就是說，挑戰不是 JavaScript 或 TypeScript——這是範式轉變。TYPO3 開發者習慣於框架引導內容結構、緩存和路線。在 Next.js + Supabase 模型中，這些調用由你決定。這很解放，但起初不知所措。與經驗豐富的 Next.js 人才進行結對編程使這個飛躍更平順。