Astro教程：后端服务与CMS集成，主流选择与接入思路

本节目标：看清 Astro 连接后端和 CMS 的整体思路，知道有哪些主流选择，而不必逐个死记。

前面几章讲的都是 Astro 自己的本领：取数据、写端点、配环境变量、按需渲染、加中间件。但真实的网站往往还要”背后有人”——存用户、存文章、做登录。**后端服务（Backend Service）**和 **CMS（内容管理系统）**就是帮 Astro 补上这些能力的外部系统。本章只做”地图”，不展开每一种的具体步骤。

什么是后端服务

后端服务是一类跑在云上的系统，帮你管数据库、用户登录、文件存储、接口生成、实时监控等”服务器侧”的事。你不用自己买服务器、装数据库，注册个账号就能用。好处是你能专心写前端，底层设施交给别人。

什么时候该考虑上后端？官方文档列了几种典型需求：

用户注册和登录（鉴权）
需要长期保存的数据
用户上传的图片等文件
自动生成 API
实时通信（比如聊天、 live 更新）
应用监控和报错收集

Note

后端服务 ≠ 按需渲染。后端是”数据存在哪、逻辑跑在哪”，按需渲染（第 36 章）是”页面什么时候生成”。两者常一起用：开了按需渲染，Astro 才能在请求时安全地连后端、读写用户数据。

主流后端服务一览

Astro 官方给了 40 多个后端接入指引，覆盖常用的几家。这里挑有代表性的几类说说：

Supabase：开源的 Firebase 替代品。提供 Postgres 数据库、登录鉴权、边缘函数、实时订阅、文件存储。功能最全，适合想”一站式”的新项目。
Neon：一种 Serverless 的 Postgres 数据库，主打随用随扩、按量计费。如果你主要缺”一个好用的数据库”，它是轻量选择。
Firebase：Google 家的后端平台，实时数据库和鉴权很成熟，老牌且生态大。
Turso / Xata：分别是边缘数据库和基于 Postgres 的数据平台，适合对延迟、查询体验有要求的场景。
Prisma Postgres：用 Prisma 这套 ORM（对象关系映射，把数据库表映射成代码里的对象）来管理 Postgres。
Appwrite、Scalekit、Sentry：分别侧重通用后端、企业级登录（B2B 鉴权）、错误监控。

Tip

别被 40 多个名字吓到。它们本质都做”数据库 + 鉴权 + 存储”这几件事的组合，只是侧重点和计费不同。先想清楚自己要哪块能力，再挑一个顺眼的就够了。

一个具体例子：Supabase 接 Astro

虽然本章不逐个展开，但拿 Supabase 看一眼”接法长什么样”很有帮助。整体分三步：

第一步，装官方 JS 客户端并把密钥放进 .env：

SUPABASE_URL=YOUR_SUPABASE_URL
SUPABASE_ANON_KEY=YOUR_SUPABASE_ANON_KEY

npm install @supabase/supabase-js

第二步，建一个客户端文件 src/lib/supabase.ts，用环境变量初始化：

// src/lib/supabase.ts
import { createClient } from "@supabase/supabase-js";

export const supabase = createClient(
  import.meta.env.SUPABASE_URL,
  import.meta.env.SUPABASE_ANON_KEY
);

第三步，写按需渲染的端点做登录。因为要读写用户、操作 Cookie，所以这些端点必须用 export const prerender = false（或在 server 模式下默认就按需）：

// src/pages/api/auth/signin.ts
import type { APIRoute } from "astro";
import { supabase } from "../../../lib/supabase";

export const POST: APIRoute = async ({ request, cookies, redirect }) => {
  const formData = await request.formData();
  const email = formData.get("email")?.toString();
  const password = formData.get("password")?.toString();

  if (!email || !password) {
    return new Response("Email and password are required", { status: 400 });
  }

  const { data, error } = await supabase.auth.signInWithPassword({ email, password });
  if (error) return new Response(error.message, { status: 500 });

  const { access_token, refresh_token } = data.session;
  cookies.set("sb-access-token", access_token, { path: "/" });
  cookies.set("sb-refresh-token", refresh_token, { path: "/" });
  return redirect("/dashboard");
};

你会看到：第 33 章的数据获取、第 34 章的端点、第 35 章的环境变量、第 36 章的按需渲染、第 37 章的 Cookie 操作——全串起来了。这正是后端集成的真实面貌。

什么是 CMS

CMS（内容管理系统）让你在 Astro 项目之外写内容、管素材。它带来可视化编辑器、统一的内容类型、多人协作等能力。最常见的一类是无头 CMS（Headless CMS）：它只负责”存内容和取内容”，不负责”怎么显示”。显示的事交给你——也就是用 Astro 把内容取回来、渲染成页面。

为什么强调”无头”？因为 Astro 只关心内容的呈现。无头 CMS 正好分工明确：它写，你取，你显示。两者通过接口或 SDK（软件开发工具包，封装好的调用库）对接。

Note

不用 CMS 行不行？当然行。Astro 自带 Markdown 支持，小站点直接用本地 Markdown 文件就够。CMS 适合”非技术的编辑也要在后台写稿""内容结构复杂且要协作”的场景。

主流 CMS 一览

官方 CMS 指引同样有 40 多种，挑几个有代表性的：

Storyblok：组件化的无头 CMS，用”Bloks（积木）“拼内容，还提供 Astro 官方集成。
Contentful、Sanity、Hygraph：都是 API 驱动、结构灵活的代表，企业里常见。
Strapi、Directus、Payload：偏”自己托管”的开源 CMS，数据握在自己手里。
WordPress：老牌博客系统，也能当无头 CMS 用，借助其 REST/GraphQL 接口取内容。
CloudCannon：官方”推荐合作伙伴”，主打基于 Git、快又安全。
还有 DatoCMS、Ghost、Prismic、TinaCMS、Keystatic 等等，各有侧重（实时编辑、Git 工作流、富文本等）。

一个具体例子：Storyblok 接 Astro

同样只看轮廓。Storyblok 提供了专门的 Astro 集成，接法分几步：

第一步，把令牌写进 .env，再装集成：

STORYBLOK_TOKEN=YOUR_PREVIEW_TOKEN

npm install @storyblok/astro vite

第二步，在 astro.config.mjs 里启用集成，并声明 Storyblok 的”Blok”对应到哪个本地 Astro 组件：

// astro.config.mjs
import { defineConfig } from 'astro/config';
import { storyblok } from '@storyblok/astro';
import { loadEnv } from 'vite';

const env = loadEnv("", process.cwd(), 'STORYBLOK');

export default defineConfig({
  integrations: [
    storyblok({
      accessToken: env.STORYBLOK_TOKEN,
      components: {
        blogPost: 'storyblok/BlogPost',
      },
      apiOptions: { region: 'us' },
    })
  ],
});

第三步，在页面里用集成提供的 useStoryblokApi() 取数据，再用 StoryblokComponent 渲染：

---
import { useStoryblokApi } from '@storyblok/astro'
import StoryblokComponent from '@storyblok/astro/StoryblokComponent.astro'

const storyblokApi = useStoryblokApi()
const { data } = await storyblokApi.get("cdn/stories/test-post", {
  version: import.meta.env.DEV ? "draft" : "published",
});
const content = data.story.content;
---
<StoryblokComponent blok={content} />

注意这又是”第 33 章数据获取 + 第 35 章环境变量”的组合。有些 CMS（如 Storyblok）还提供 Astro 集成，用法更顺手；另一些只给 JS SDK，你就直接用 fetch() 或 SDK 取数。

社区里的做法参考

除了官方文档，社区文章也能给灵感。比如 dev.to 上有用 microCMS + Vercel 搭博客的实战（对应 005 篇）、用 Astro Server Islands 让页面快又不丢交互性的讨论（对应 022 篇）、以及把 Astro + FastAPI 部署到 Cloudflare 的 SaaS 例子（对应 017 篇）。这些不是官方必修内容，但能帮你理解”别人实际怎么搭”。

Tip

选 CMS 或后端时，先看它有没有 Astro 集成或官方 JS SDK，再看重不重”实时""自托管""协作”。别一上来就全接，先接一个最小可用版本跑通再说。

小结

后端服务和 CMS 是 Astro 的”外部搭档”：后端管数据、登录、存储；无头 CMS 管内容、编辑、协作。两者都通过环境变量 + 客户端/SDK + 按需渲染端点接入 Astro，本质上都是前面几章知识的组合运用。官方指引覆盖 40 多种后端和 40 多种 CMS，不用全记，按需求挑一两个顺眼的即可。

到本章为止，数据、API、环境变量、按需渲染、中间件、后端与 CMS 这条”动态能力”主线就讲完了。

后端服务与 CMS 集成概览

什么是后端服务

主流后端服务一览

一个具体例子：Supabase 接 Astro

什么是 CMS

主流 CMS 一览

一个具体例子：Storyblok 接 Astro

社区里的做法参考

小结