用 Astro + Cloudflare 逐步扩展官网功能的整体设计

使用 Astro 和 Cloudflare Pages 做静态网站时，一开始只要能快速、安全地发布页面就足够了。

但运营一段时间后，通常会想加入浏览器编辑、多语言页面、AI 聊天引导、从服务页传递表单上下文，以及评论功能。

这篇文章是一个实现索引：先判断功能属于哪一层、按什么顺序加入、接下来该读哪篇详细文章。例子来自 Acecore 官网，但方法可以直接套用到其他 Astro + Cloudflare 网站。

结论

官网扩展功能时，先把职责拆开：

层次	职责
Astro	页面、博客、OGP、RSS、sitemap、UI
Cloudflare	Pages 发布、Pages Functions、D1、Turnstile
GitHub	PR 审核、CMS 差异、翻译差异、历史记录
Sveltia CMS	日文 source、作者、标签、图片
OpenAI API	咨询 AI 的回答生成
Pagefind	为审核后的静态 HTML 建立站内搜索索引

能静态生成的内容保持静态。需要请求时处理的部分才进入 Cloudflare Pages Functions。

动态功能只做小 API

咨询 AI 和评论功能都采用相同模式：

• Astro 负责 UI
• Pages Functions 负责 API 边界
• secret、D1 binding、Turnstile secret、Origin 检查不暴露给浏览器

网站不会因此变成完整的应用服务器。它仍然以静态页面为主。

CMS 是编辑入口，不是运行时数据库

Sveltia CMS 的职责是让内容编辑变成 Git 差异。

日文博客、作者、标签、图片和日文 JSON 文案都通过 CMS 编辑，然后经过 GitHub PR、build 和 review 再发布。

这样可以保留静态网站的可审查性。

多语言是静态内容生成

多语言页面不是浏览器 UI 翻译，而是实际生成各语言 Markdown 和 HTML。

因此每种语言都有 URL、title、description、OGP、JSON-LD、RSS、sitemap 和 hreflang。

联系导线要分工

AI 聊天适合帮助访客判断该看哪个服务。服务 CTA 适合把已经阅读的服务上下文传到表单。表单负责记录正式咨询。

把这些都当作同一个“联系我们按钮”会让体验变弱。

AI 输出不是可信 HTML

AI 回答可以包含 Markdown 风格的链接，但不能直接放进 innerHTML。

链接需要 trim、allowlist 检查，并用 DOM API 渲染。无法确认安全的链接保留为文本。

评论功能留在 Cloudflare 内

评论功能没有使用外部评论服务。

Pages Functions 处理 GET/POST，D1 保存评论，Turnstile 验证提交，Origin、hostname、rate limit 和内容过滤决定是否接受。

对小型公司博客来说，这比引入完整社区系统更合适。

按目的阅读

不需要从头读完。先从想加入的功能开始。

想做的事	先读文章
从浏览器编辑文章和图片	Sveltia CMS 导入指南
让多语言页面进入搜索索引	用 Sveltia CMS 运营多语言博客
用 AI 聊天引导访客	在 Astro 网站中加入咨询 AI 聊天的技术设计
在 AI 回答中安全渲染链接	安全渲染 AI 聊天回答中的 Markdown 链接
把服务页上下文传给联系表单	将服务 CTA 的上下文传给联系表单
不依赖外部服务添加评论功能	只用 Cloudflare 为 Astro 博客添加评论功能

推荐导入顺序

如果要在其他网站采用同样结构，顺序建议如下：

1. 先用 Astro 固定静态页面、博客、RSS、sitemap 和 OGP。
2. 用 Sveltia CMS 编辑日文 source。
3. 将多语言页面生成成静态 HTML。
4. 加入 AI 聊天和服务 CTA。
5. 固化 Markdown 链接、表单 prefill、Origin 检查和 rate limit。
6. 真正需要交流时，再在 Cloudflare 内加入评论功能。

总结

Astro + Cloudflare 的官网不必停留在静态公司介绍页。

只要把职责分清，静态页面、CMS、多语言、咨询 AI、表单导线和评论功能可以在同一个架构里共存。

把这篇作为入口，就可以只选择自己网站需要的功能，同时不破坏静态网站的基础。