这个博客为什么选 Cloudflare 全家桶

我做 01mvp-blog-starter 的时候，最早定下来的方向很明确，尽量放在 Cloudflare 上。

原因不复杂。

个人博客最需要的并非一台很强的服务器。它更需要稳定的访问入口、足够低的维护成本、能被 AI 自动化的资源创建流程，以及未来可扩展的空间。

Cloudflare 这套东西刚好贴合这个需求。

前端和服务端，TanStack Start

这个项目用 TanStack Start 做全栈入口。

它的好处是前端路由、服务端函数、SSR、部署入口都在一个 TypeScript 项目里。对 AI 来说，这种结构也更容易理解。AI 不需要同时在多个仓库、多个框架之间来回跳。

页面是 React，路由是 TanStack Router，构建是 Vite Plus。后台、文章页、文档页、API 都在同一个 Web 应用里。

这让模板更适合被 AI 维护。

AI 改一个功能时，可以顺着路由、组件、服务端函数、数据库 schema 一路读下去。它不需要猜一个传统 CMS 的插件体系，也不需要绕过一堆历史包袱。

Worker，博客的运行入口

部署到 Cloudflare Workers 后，博客本身就是一个边缘应用。

文章列表、文章详情、RSS、站点地图、后台 API、登录回调，都从 Worker 处理。

对个人博客来说，这样有几个实际好处。

部署很轻。没有服务器要登录，没有系统包要升级，也没有 Nginx 配置要维护。

扩展方便。后面要加后台接口、评论审核、邮件通知、导出备份，都在同一个运行环境里。

AI 自动化也更清楚。Skill 可以直接调用 Wrangler 和 Cloudflare API，创建资源、绑定资源、部署 Worker、检查结果。

D1，文章和账号数据

博客需要数据库。

文章、标签、系列、评论、用户、会话、API Token、邮件偏好，这些都需要稳定存储。

我选 D1，是因为它和 Workers 的绑定方式很直接。模板里用 Drizzle 管 schema，代码里用类型约束字段。AI 读到 schema 后，基本能知道文章有哪些字段，评论有哪些状态，后台 API 应该怎么改。

D1 也很适合个人博客这种读多写少的场景。

写文章、改设置、发评论，频率不会特别高。读文章、访问列表、生成 RSS，才是主要流量。

KV，做短期缓存

KV 在这个项目里主要做缓存。

比如已发布文章列表、标签列表、站点地图路径。这些数据不需要每次都查数据库。

更新文章、标签、系列之后，系统会清掉相关缓存。读者访问时，再重新生成。

这一步没有什么炫技成分。它只是让一个小博客在高访问时更稳一点，也让 Cloudflare 的资源使用更克制。

R2，图片和备份

文章图片、导入包、导出包、站点备份，放在 R2。

R2 有免费额度，但通常需要 Cloudflare 账号绑定付款方式才能开通。这一点我在文档里写得很明确。

如果你暂时不想绑定付款方式，也可以先把图片功能和导出备份放一放。博客先跑起来更重要。

后面你真的开始写文章了，再补 R2 也来得及。

Better Auth，账号系统

博客还包含动态能力。

后台需要管理员登录。评论区可能需要读者账号。以后如果加订阅、邮件通知、私密文章，也会需要一个稳定的账号系统。

Better Auth 的优势是比较现代，和 TypeScript 项目配合舒服。这个模板里已经把管理员、读者、评论状态、邮箱偏好这些基础能力放进去了。

GitHub 登录和 Google 登录是可选项。

你可以先用邮箱账号登录后台。等需要社交登录时，再创建 OAuth 应用，填入对应密钥。

Email，先当进阶功能

邮件功能很有用。

邮箱验证码、密码重置、评论回复通知、博客周报，这些都依赖邮件发送。

但 Cloudflare Email Sending 目前需要 Workers Paid。对于一个新手来说，我不希望这一步变成阻塞点。

所以模板把邮件设计成可选。

不开启邮件时，相关能力可以先关掉。等 Cloudflare 未来给 Email Service 更多免费额度，或者你愿意升级账号，再打开也行。

自定义域名，正式站建议准备

Cloudflare Workers 默认会给一个 *.workers.dev 地址。

测试没问题。

但如果你面向中国大陆读者，这个地址在很多网络环境里打不开或不稳定。正式公开时，我建议绑定自己的域名。

绑定域名后，访问入口更可控，链接也更像长期资产。

如果你要长期稳定、大量公开访问，还要考虑备案和接入要求。这个项目能帮你把博客部署出来，但域名和访问合规依然要按你的使用场景处理。

为什么这套栈适合 AI

我对 01mvp-blog-starter 的要求，重点不在功能数量。

我更希望它的边界清楚。

一个仓库。一个 Web 应用。一个数据库 schema。Cloudflare 资源都有明确绑定。初始化流程写在文档和 Skill 里。AI 读完之后知道自己该做什么，也知道哪些地方需要用户手动处理。

这很重要。

很多 AI 项目失败，问题经常出在工程边界不清楚。模型会写代码，但它不知道该往哪里写、该停在哪里。

这个项目想解决的就是这个问题。

让 AI 不再从一张白纸开始胡乱发挥。

让它拿到一套已经跑通的博客骨架，然后把你的网站真正部署出来。