TYPO3 无头模式 vs 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（完全无头）
另一方面，你有 Next.js 管理你的前端和服务器端逻辑。Supabase（PostgreSQL、身份验证、文件存储和实时功能的绝妙组合）处理你的后端。这里没有 TYPO3，各位。你正在放弃旧的 CMS，以获得纯粹的灵活性和现代 JavaScript 原生设置。
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 无头做得好的地方
- 编辑体验保持不变。 TYPO3 熟悉的后端意味着内容编辑无需重新培训。
- 保留现有内容。 你的设置不会消失。你的所有内容、翻译和媒体？它们会保留下来。
- 多语言支持岩石。 TYPO3 拥有我见过的一些最好的语言处理。
- 企业级功能。 从工作区到计划发布的一切都已准备好。
EXT:headless 的问题
- TYPO3 不会消失。 你需要懂 PHP 的人，他们理解 TYPO3，而他们并不到处都是。
- 复杂的托管。 你在处理 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 |
底线？虽然使用 Supabase 的未缓存 TTFB 更好，但 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 开发用于轻量级内容丰富网站，那值得看一下。
想讨论你的具体需求吗？我们在这里帮助评估什么对你独特的情景有意义——伸出手，我们承诺诚实评估，即使它是"坚持你所知道的"。
常见问题
EXT:headless TYPO3 在 2025 年是否生产就绪？ 是的，绝对的。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 的 Metadata API 在布局中。只要你的 TYPO3 设置是可靠的，SEO 数据应该遵循。集成扩展如 EXT:yoast_seo，它将与无头配置很好地配合。
Supabase 是否符合企业级内容交付？ 当然可以。Supabase Cloud 在 AWS 上运行，在 Pro 计划上提供 99.9% 的正常运行时间，在团队计划上提高到 99.95%（检查 2025 年的费率）。对于 CDN 缓存（Vercel 的边缘网络、Cloudflare），Supabase 主要确保写入和实时功能可靠性。对于关键企业用途，自托管 Supabase 以获得最大控制。
没有 TYPO3 我们如何处理图像处理？ TYPO3 本机处理图像——裁剪、调整大小、格式翻转。没有它，设置你的图像工作流程。2025 年的顶级竞争者是：Next.js 图像优化（内置、Vercel 支持）、Cloudinary（免费启动、严肃使用需要付费计划）或 imgix（起价 $100+/月）。Supabase Storage 处理原始但不转换。
我们能否从 TYPO3 无头逐步迁移到完全无头？ 绝对的，把它想象成一个平滑的计划。从无头 TYPO3 开始，隔离你的前端。逐渐将内容从 TYPO3 转移到 Supabase 或你选择的 CMS——从更简单的类型开始。在阶段中，你的 Next.js 前端从两个源操作数据。
从 TYPO3 团队过渡到 Next.js + Supabase 的学习曲线是什么样的？ 现实的加速是大约三到六个月。也就是说，挑战不是 JavaScript 或 TypeScript——这是范式转变。TYPO3 开发者习惯于框架指导内容结构、缓存和路由。在 Next.js + Supabase 模型中，那些呼叫都是你的。这既是解放也是最初的压倒。与经验丰富的 Next.js 人员进行配对编程使这种飞跃平滑得多。