Cloudflare：个人云端平台的低成本基础设施

Blog 版：在 F-SJ Blog 阅读

为什么要单独写 Cloudflare

在 Blog 和私人 Email 两个项目里，Cloudflare 出现得太频繁了。

Blog 用它来托管网页、绑定域名、提供 HTTPS、部署 Pages Functions、保存 D1 数据；私人 Email 用它来管理 DNS、接收邮件、运行 Worker、部署 Inbox 页面。继续往后做搜索、AI 问答、防垃圾评论、访问控制、文件存储，也还会继续碰到 Cloudflare。

所以它不只是一个“域名解析工具”，也不只是一个 CDN。对个人开发者来说，它更像一套低成本的云端基础设施：域名、网站、API、数据库、邮件、安全和 AI 能力，都可以围绕同一个平台逐步搭起来。

关联笔记：

Cloudflare 是什么

Cloudflare 最早被很多人认识，是因为 CDN、DNS 和网站安全。但今天的 Cloudflare 已经更像一个边缘云平台。

“边缘”的意思是：代码、缓存、网络和部分数据能力尽量靠近用户所在地区运行。对用户来说，访问更快；对开发者来说，不需要一开始就买服务器、配 Nginx、处理证书和部署环境。

可以把 Cloudflare 理解成几层能力：

网络入口：DNS、CDN、HTTPS、缓存、域名接入。
网站部署：Cloudflare Pages。
后端逻辑：Cloudflare Workers。
数据能力：D1、KV、R2、Durable Objects、Queues。
邮件能力：Email Routing。
安全能力：WAF、DDoS 防护、Turnstile、Zero Trust。
AI 能力：Workers AI、Vectorize。

官方文档入口：

DNS：所有服务的入口

DNS 是域名系统。简单说，它负责告诉互联网：某个域名应该访问哪里。

Blog 绑定域名时，需要 DNS；Email 接收和发送时，需要 DNS；后续如果要做 API、后台、对象存储、图片服务，也还是需要 DNS。

在我们的项目里，DNS 做了几件事：

把 Blog 子域名指向 Cloudflare Pages。
把 Inbox 子域名指向邮件管理页面。
给 Email Routing 配置收信记录。
给 Resend 配置发信验证记录。
让 HTTPS 证书和代理能力由 Cloudflare 自动接管。

DNS 文档：

Cloudflare DNS

Pages：托管静态网站

Cloudflare Pages 是静态网站和前端项目托管服务。

Blog 项目使用 Hexo 生成静态文件，然后 Cloudflare Pages 负责把这些文件发布到公网。它可以连接 GitHub 仓库，代码推送后自动构建和部署。

这对个人 Blog 很友好：

不需要自己买服务器。
不需要手动配置 Web 服务。
可以自动生成 Preview 环境。
可以绑定自定义域名。
可以自动启用 HTTPS。

在我们的 Blog 中，Pages 是正式站点和测试站点的部署核心。

Pages 文档：

Cloudflare Pages

Pages Functions 和 Workers：给静态网站加后端

纯静态网站没有真正的后端 API。但很多功能需要后端：评论、统计、邮件通知、搜索、权限验证、表单提交。

Cloudflare Workers 是边缘函数服务；Pages Functions 是 Pages 项目里的函数能力。它们都可以让我们不用维护服务器，也能写 API。

在 Blog 中，Pages Functions 负责轻量接口，例如访问统计、评论反馈、搜索和 AI 相关接口。

在 Email 中，Workers 负责邮件系统后端，例如收件处理、邮件接口、地址管理、发信代理。

Workers 文档：

Cloudflare Workers

D1：轻量数据库

D1 是 Cloudflare 提供的边缘 SQLite 数据库。

它适合个人站点和小型项目存放结构化数据，例如：

文章浏览量。
点赞或帮助反馈。
评论元数据。
简单配置。
小型应用数据。

在 Blog 中，D1 负责保存统计和互动类数据。它让静态 Blog 不再只是“纯展示页面”，而是可以拥有少量动态能力。

D1 文档：

Cloudflare D1

KV、R2、Queues：以后还能扩展什么

除了 D1，Cloudflare 还有几类常用数据和异步能力。

KV 是键值存储，适合保存配置、缓存、小型状态。

R2 是对象存储，适合放图片、附件、备份文件、构建产物。它类似对象存储服务，但和 Cloudflare 网络结合更紧。

Queues 是队列服务，适合把耗时任务异步处理。例如评论通知、邮件发送、AI 索引更新，都可以先放进队列，再由后台慢慢处理。

Email Routing：自定义域名收信

Email Routing 让 Cloudflare 可以接收发往自定义域名的邮件。

它适合个人域名邮箱的收信入口。我们有了域名后，就可以设计自己的邮件地址体系，再让 Cloudflare 负责接收和路由。

在私人 Email 项目中，Email Routing 负责收信入口，Worker 和 Web Inbox 负责后续处理和展示。

Email Routing 文档：

Cloudflare Email Routing

Turnstile、WAF、Zero Trust：安全能力

个人项目也会遇到安全问题，例如垃圾评论、恶意请求、后台入口暴露、爬虫和滥用。

Cloudflare 可以继续提供安全层：

Turnstile：人机验证，可以替代传统验证码，适合评论、登录、表单防滥用。
WAF：Web 应用防火墙，用规则拦截可疑请求。
DDoS 防护：缓解大量恶意流量。
Zero Trust / Access：保护后台、预览环境或内部工具入口。

这些能力让个人项目不用一开始就自己写完整安全体系。

Workers AI 和 Vectorize：AI 能力

Cloudflare 也在提供 AI 相关能力。

Workers AI 可以在 Cloudflare 上调用模型能力；Vectorize 是向量数据库，可以做语义搜索、知识检索和问答基础设施。

对 Blog 来说，这些能力以后可以用在：

文章语义搜索。
个人知识库问答。
自动标签或摘要。
根据文章内容推荐相关文章。
评论或表单内容审核。

为什么它适合个人项目

Cloudflare 适合个人项目，不是因为它能替代所有云服务，而是因为它把很多基础能力放在同一个入口里。

对个人开发者来说，这很重要：

可以从免费或低成本能力开始。
不需要一开始维护服务器。
域名、部署、HTTPS、CDN、安全、函数、数据库可以逐步打开。
每个功能都可以小步试错。
和 GitHub、AI 编程工具配合很好。

这和我们的 Blog 搭建思路一致：先把最小可用版本跑起来，再不断加能力。不是一次性做一个庞大平台，而是用 Cloudflare 提供的积木，一块一块搭。

它不只是“薅羊毛”

从个人角度看，Cloudflare 的免费和低成本额度确实很有吸引力。很多学习项目、个人站点、小工具，都可以先用这些能力跑起来。

但更准确的说法不是滥用免费资源，而是合理使用平台给个人开发者的低门槛能力。这样既能降低试错成本，也能学习真实云端架构。

如果项目流量变大，或者开始承载商业用途，就应该重新评估额度、账单、数据合规和稳定性。

我们当前已经用到的 Cloudflare 能力

当前 Blog 和 Email 项目已经用到：

DNS：管理子域名和邮件记录。
Pages：部署 Blog 和 Inbox 前端。
Pages Functions：给 Blog 增加 API。
Workers：运行 Email 后端和邮件发送代理。
D1：保存 Blog 统计和互动数据。
Email Routing：接收自定义域名邮件。
HTTPS / CDN：让站点更容易公开访问。
Preview / Production 部署：区分测试环境和正式环境。

后续可以继续考虑：

R2：存放图片、附件、备份。
KV：保存轻量配置和缓存。
Queues：处理异步任务。
Turnstile：防垃圾评论和表单滥用。
Zero Trust：保护后台和预览入口。
Workers AI + Vectorize：做文章语义搜索和个人知识库问答。

总结

Cloudflare 对这个个人平台来说，是一个底座。

Blog、Email、域名、统计、评论、发信、收信、后续 AI 搜索，都可以放在这个底座上逐步扩展。

它最大的价值，是让个人开发者不用一开始就拥有完整运维能力，也能搭出接近真实生产环境的系统。配合 GitHub 和 AI 编程工具，很多原来“想做但一直放着”的云端项目，都可以变成能快速试错、逐步上线的小项目。