Back

你能把 Notion 用作网站后端吗?

OpenReplay Team OpenReplay Team

Feb 18, 2026 · 2 min read

你能把 Notion 用作网站后端吗?

你可能见过这样的演示:有人完全用 Notion 搭建了一个作品集网站,部署到 Vercel,并声称零订阅成本。这种方式的吸引力显而易见——你的客户在他们已经熟悉的工具中更新内容,而你完全跳过了 WordPress 的繁琐开销。

但你真的能把 Notion 用作生产环境网站的后端吗?答案是可以,但有重大限制。本文将剖析其架构、真实的工程权衡,以及这种方法何时适用、何时会崩溃。

核心要点

  • Notion 可以通过将其 API 与用 Next.js 或 Astro 等框架构建的自定义前端配合,作为轻量级无头 CMS 使用。
  • 这种方法最适合小型内容站点、作品集、原型和 MVP,即编辑体验比规模更重要的场景。
  • 严格的 API 速率限制、会过期的文件 URL、不完整的区块类型支持以及仅信号通知的 webhook 都会带来真实的工程约束。
  • 静态站点生成配合激进缓存是必需的,以避免运行时依赖 Notion 的可用性。
  • 如果你的项目需要高流量、复杂的关系数据、实时更新或严格的正常运行时间保证,请选择专门构建的无头 CMS。

“Notion 作为后端”的真正含义

首先,要区分两个不同的概念:Notion Sites(他们的内置发布功能)和将 Notion API 用作你自己前端的数据层。

Notion Sites 让你一键发布任何页面。它很简单但有限——你只能使用 Notion 的样式和域名结构。

将 Notion 用作无头 CMS 则不同。你构建一个自定义前端(通常使用 Next.js、Astro 或类似框架),从 Notion 的 API 获取内容,并按你想要的方式渲染。这就是驱动那些歌剧歌手作品集示例网站的架构——静态页面配合从 Notion 数据库后端拉取的动态部分。

典型架构

基于 Notion 的网站通常遵循这种模式:

  1. 内容存储在 Notion 数据库中(博客文章、活动、作品集项目)
  2. 你的服务器或构建过程调用 Notion API 获取该内容
  3. 渲染层将 Notion 的区块结构转换为 HTML
  4. **静态生成或 ISR(增量静态再生成)**缓存结果,这样你就不必在每次请求时都访问 Notion

像 react-notion-x 这样的库处理渲染步骤,将 Notion 的区块类型转换为样式化的 React 组件。你可以获得标注、代码块、表格和折叠面板,而无需自己构建每一个。

适用场景

在特定场景下,使用 Notion API 构建网站表现出色:

小型内容站点和作品集。 音乐家的活动日历、自由职业者的项目展示或创业公司的招聘板。内容更新不频繁,而且更新内容的人不想学习新的 CMS。

原型和 MVP。 当你需要快速上线且内容模型简单时,Notion 完全消除了后端需求。你可以在投资适当的基础设施之前验证想法。

内部工具和文档。 已经在使用 Notion 的团队可以对外公开某些页面,而无需迁移内容。

真正的价值主张:你的非技术客户在他们每天已经使用的工具中编辑内容。无需培训。

局限性

以下是 Notion 与传统 CMS 比较的真实情况:

速率限制很严格。 Notion API 限制你大约每秒 3 次请求。对于构建时获取,这意味着一个有 500 个页面的站点需要几分钟才能重建。对于运行时获取,你需要激进的缓存策略。

文件 URL 会过期。 Notion 中托管的图片和文件返回临时 URL(通常有效期为一小时)。你必须通过自己的服务器代理这些文件,或在构建时下载并重新托管它们。

某些区块类型不受支持。 API 不会返回你在 Notion 中看到的所有内容。同步块、某些嵌入内容和某些数据库视图可能无法正确渲染或根本不渲染。

Webhook 仅提供信号。 Notion webhook 告诉你某些内容发生了变化,但不包含实际数据。收到通知后,你仍需要重新获取内容。

没有关系查询。 与真正的数据库不同,你无法高效地跨 Notion 数据库进行联接。复杂的内容模型会变得很痛苦。

Notion 可能宕机。 如果你在运行时获取数据且 Notion 的 API 不可用,你的网站就会崩溃。带回退的静态生成可以缓解这个问题,但它仍然是你无法控制的依赖项。

何时选择其他方案

如果你需要以下功能,请跳过 Notion 作为后端:

  • 需要一致的低于 100 毫秒响应的高流量站点
  • 复杂的关系数据(带变体的产品、嵌套类别)
  • 无需重建延迟的实时内容更新
  • 严格的正常运行时间保证
  • 大量内容(数千个页面)

对于这些情况,专门构建的无头 CMS 平台或带管理界面的简单数据库会更好地为你服务。

结论

对于编辑体验比规模更重要的小型站点、工具和 MVP,Notion 可以作为轻量级无头 CMS 使用。架构很直接:在构建时获取,激进缓存,并使用渲染库处理 API 的怪癖。

只是不要把它误认为是生产数据库。了解速率限制,为过期的 URL 做好计划,并在项目超出其能力范围时准备好迁移路径。

常见问题

Notion 返回的临时文件 URL 通常在一小时后过期。最可靠的解决方案是在构建步骤中下载所有图片,并从你自己的托管服务或 CDN 提供它们。或者,你可以设置一个服务器端代理,按需获取和缓存图片,在它们过期前刷新。

Notion 不太适合电商。它缺乏处理带变体产品所需的关系查询,没有事务支持,其速率限制使实时库存或定价更新不切实际。对于任何商店,专门构建的无头 CMS 或配有管理界面的数据库都是更好的选择。

如果你在运行时获取内容,当 Notion API 不可用时,你的网站会崩溃。标准的缓解措施是使用静态站点生成,这样页面会预先构建并从 CDN 提供。带 stale-while-revalidate 回退的增量静态再生成也有帮助,它在尝试后台刷新时提供缓存内容。

你可以实现带延迟的请求队列,以保持在大约每秒三次请求的限制内。在构建之间本地缓存 API 响应,这样只重新获取更改的页面也会显著有帮助。对于非常大的站点,考虑使用中间数据层,按计划从 Notion 同步,而不是在构建时查询 API。

Understand every bug

Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.

OpenReplay

More articles from OpenReplay Blog