选择cloudflare，给我的博客带来了什么

写在前面

搭建「栏轩阁」个人博客的过程中，后端架构是我反复思考最多的部分。既要足够轻量（个人博客，没有高并发压力），又要功能齐全（评论、统计、AI 对话、邮件归档……），还要尽可能降低成本。

最终的选择是 Cloudflare。不是因为它大厂光环，而是它提供的服务矩阵恰好覆盖了我全部的 backend 需求，而且全部跑在同一套 Free / 低付费计划里。

一、基础层：DNS + CDN

1. 自定义域名 + DNS — 整个博客的基石

「栏轩阁」的前端是部署在 GitHub Pages 上的静态站点，后端 API 跑在 Cloudflare Workers 上。Cloudflare DNS 就是连接这两者的中枢：

博客访问（用户 → 浏览器）
       ↓
  lxpavilion.top（Cloudflare DNS）
       ├── A / CNAME 记录 → GitHub Pages（静态站点）
       └── api.lxpavilion.top → Workers（后端 API）

GitHub Pages 域名托管： 博客主域名 lxpavilion.top 通过 Cloudflare DNS 的 CNAME 记录指向 GitHub Pages 分配的域名。Cloudflare 自动代理（橙色云朵开启）后，所有访问流量先经过 Cloudflare 边缘节点再回源到 GitHub 服务器，实现了两个效果：

全球加速：GitHub Pages 的源服务器在美国，国内访问速度不理想；开启 Cloudflare 代理后，静态资源从最近的 CDN 节点交付，加载速度明显提升
隐藏源 IP：访问者看到的只有 Cloudflare 的 IP，GitHub Pages 的真实地址不会暴露

API 子域名： api.lxpavilion.top 通过 DNS 记录指向 Workers，所有前端通过这个统一入口调用后端 API，解决了前端直接请求第三方 API 的跨域和 Token 安全问题（详见下文"后端代理"章节）。

延伸配置： Cloudflare DNS 还用于配置 Newsletter 发件域名的 SPF/DKIM 记录——无论是 Buttondown 还是 MailerLite，都需要在 DNS 中添加特定的 TXT 记录来验证域名所有权和发件身份。

2. CDN + Cache API — 加速层

Cloudflare CDN 提供全球节点缓存静态资源，博客的 HTML、CSS、JavaScript 和图片都通过 CDN 加速分发。配合 Cache API 可以在 Workers 中精细控制缓存策略。

对 GitHub Pages 的加速效果： GitHub Pages 没有自家的 CDN 加速能力，国内某些地区的访问延迟可能高达数百毫秒。接入 Cloudflare 后，静态资源的 TTFB（首字节时间）从平均 300-500ms 降低到 50-100ms 左右。

缓存刷新： 博客更新后，POST /purge 端点调用 Cloudflare API 按 URL 或前缀精准刷新缓存，配合博客后台的"刷新缓存"按钮，完全可控，不用担心旧内容被缓存。

IndexNow 搜索引擎自动推送： 每次 POST /purge 触发 CDN 缓存刷新时，Cloudflare 的 Automatic IndexNow 功能会自动向支持的搜索引擎（Bing、Yandex 等）推送内容更新通知。

在此基础上，我还做了双重兜底：

Bing Webmaster 站点绑定：在 Bing Webmaster Tools 中关联站点并验证所有权，确保收录入口畅通
自定义 IndexNow API 请求：通过 Workers 在发布文章时主动调用 IndexNow API，作为 Cloudflare 自动推送的补充，进一步缩短收录延迟

最终链路：发布文章 → Purge 缓存 → Cloudflare Automatic IndexNow + 自定义 API 请求 → 搜索引擎快速收录

3. Cloudflare Workers — 后端底座

这是整个博客的后端底座。一个名为 blog-api 的 Worker 处理了几乎所有实时逻辑。

路由覆盖：

端点	方法	用途
`/ping`	GET	健康检查
`/`	POST	站点数据统计分析（GraphQL Analytics）
`/platform`	GET	聚合 CSDN / 掘金 / 博客园的平台数据
`/rss?url=...`	GET	RSS 代理抓取
`/purge`	POST	CDN 缓存刷新
`/ai/chat`	POST	AI 聊天（Live2D 看板娘）
`/api/auth/*`	—	登录注册、GitHub OAuth
`/api/view/*`	—	文章阅读计数
`/api/comment/*`	—	自建评论系统
`/api/email/*`	—	邮件管理

如果不用 Workers，这些功能我至少需要一个 Node.js 服务器 + 数据库 + 定时任务组合。

真实体验：

冷启动确实存在，但 Smart Placement 开启后体感改善很多
Free Plan 每天 100,000 次请求额度，个人博客完全用不完
wrangler deploy 一键部署，CI/CD 友好

4. 后端代理 — 告别 Token 保留与 CORS 问题

获取其他平台的数据时（CSDN、博客园、稀土掘金的文章爬虫、GitHub API 登录与评论、RSS 订阅抓取等），以前直接在前端调用会遇到两个问题：

跨域（CORS）：浏览器限制前端直接请求第三方 API
Token 暴露：API Key 和 Token 无法安全地保留在前端代码中

Workers 作为 BFF（Backend For Frontend） 统一代理层，完美解决了这两个问题：

前端请求 → api.lxpavilion.top/Worker → Workers 代理转发 → 第三方 API
                                      ↕
                              Token 存在环境变量中，永不暴露

所有第三方 API 的 Token 都通过 wrangler secret put 存储在 Worker 环境变量中，前端只与自己的域名通信，既安全又干净。

三、存储层：D1 关系型数据库

5. Cloudflare D1 — 分布式 SQLite

博客早期图片等静态数据通过 GitHub 管理 + 流水线部署，但随着实时性数据需求的增加——登录功能、评论系统、阅读计数——必须引入数据库。

最开始我犹豫过是否用 SQLite 做生产数据库，但 D1 证明了这个担心是多余的。它本质上是分布式的 SQLite，天然和 Workers 同区域部署，延迟极低。

我的 D1 建了 6 张表：

表名	用途
`user`	用户体系（支持 GitHub OAuth 登录）
`article_view`	文章阅读计数，按 IP + UserAgent + 文章 ID 去重
`comment_reaction`	评论互动数据
`comment_upvote`	评论点赞数据
`emails`	邮件归档（配合 Email Routing 自动入库）
`settings`	键值配置（如邮件转发地址）

真实体验：

最大亮点：和 Workers 同区域部署，延迟极低
备份简单：一条 wrangler d1 backup 命令搞定所有数据
写扩散型博客场景完全够用，并发量对 D1 来说小菜一碟
迁移工具 wrangler d1 migrations create + apply 比 Prisma 还轻量，无需额外的 ORM

四、服务层：邮件、AI 与分析

6. Cloudflare Email Routing — 邮件归档系统

这是我用过的所有 Cloudflare 服务中最让人惊喜的功能。通过 Email Routing 配合 Worker 的 email() 事件处理，实现了完整的收发 + 归档 + 转发链路。

为什么不用第三方邮箱服务？

对比维度	第三方邮箱（Zoho / QQ 域名邮箱）	Cloudflare Email Routing
自定义域名	部分支持	✅ 完全支持
邮件归档	依赖厂商	✅ 存自己 D1
转发灵活性	固定规则	✅ Worker 自定义逻辑
隐私控制	厂商可访问	✅ 数据在自己手里
路径多样化	有限	✅ 无限（hi@ / notify@ / admin@ 等）

工作流：

发件人 → hi@lxpavilion.top → Email Routing（DNS MX 记录）
                                  ↓
                            Worker email 事件处理
                                  ↓
                          ┌── 解析 MIME（postal-mime）
                          ├── 存入 D1（emails 表）
                          ├── 查询转发地址（DB settings 表）
                          └── message.forward() → 我的主邮箱

路径多样化示例： 同一个域名 @lxpavilion.top 的不同前缀，可以走完全不同的处理链路：

邮箱地址	用途	处理方式
email@lxpavilion.top	个人主路径，接收博客评论、读者来信等	Worker 中转 → 解析 MIME → 存入 D1 归档保存
notify@lxpavilion.top	通知路径，接收服务通知、验证邮件等	直接转发到真实邮箱，不存入 D1，避免垃圾广告污染归档

这样设计的好处是：主邮箱的所有通信记录都在自己的数据库里，隐私可控；通知邮箱直接透传，省去不必要的存储开销。

配套的管理 API（/api/email/*）和博客后台页面，可以浏览、搜索、删除历史邮件，以及设置转发目标地址。

关于 Newsletter 发件： 虽然 Email Routing 可以处理入站邮件，但出站订阅推送需要通过专业的 Newsletter 平台来做。我的方案是 MailerLite（免费版），配合 Cloudflare DNS 验证发件域名，实现零成本的 RSS 自动推送。详细配置过程可参考免费订阅服务升级：MailerLite 完全指南（与 Buttondown 对比）。

真实体验：

完全替代了 Zoho Mail / QQ 邮箱域名邮箱等方案
核心逻辑不到 200 行代码，实现了收件 + 归档 + 转发全链路
所有邮件数据存在自己的 D1 里，隐私完全可控

7. Cloudflare Workers AI — 看板娘智能对话

博客的 Live2D 看板娘（Ava / Diana 双角色）背后跑的是 Workers AI。不需要自己去部署模型、管理 GPU、配置 API key。

模型： @cf/qwen/qwen3-30b-a3b-fp8（通义千问变体）

集成方式：

const response = await env.AI.run("@cf/qwen/qwen3-30b-a3b-fp8", {
  messages: [{ role: "system", content: systemPrompt }, ...history],
  max_tokens: 2048,
});

真实体验：

首 token 约 1–2s，对聊天场景完全可以接受
代码量极少：绑定好之后只有一行 env.AI.run()，没有 API key 管理，没有鉴权配置
我捕获了 rate limit 错误（code 3036，配额用完），优雅降级为"休息一下，待会再聊"的提示

8. Cloudflare Analytics API — 站点统计看板

没有用 Google Analytics 或 Umami 等第三方统计工具。Workers 通过 GraphQL Analytics API 直接拉取 CDN 层的访问数据：

实时请求量、带宽、状态码分布
热门 URL 排行
访客地理分布
缓存命中率

这些数据通过 / 端点聚合后，展示在博客后台的统计看板中。数据源来自 CDN 边缘节点，比第三方 JS 脚本统计更准确（不会被广告拦截器屏蔽）。

五、优化层：加速与缓存

9. Smart Placement — 智能部署

Workers 的 Smart Placement 会自动把 Worker 部署到最合适的位置——靠近用户还是靠近数据处理端（如 D1），由 Cloudflare 的智能调度决定。

配置仅一行：

"placement": { "mode": "smart" }

开启后 API 响应时间降低了约 30%，而且是免费的优化。

六、账单：到底花了多少钱？

服务	费用	备注
Workers	Free	10 万 req/day，个人博客用不完
D1	Free	5GB 存储 + 每月 500 万读 / 10 万写
Workers AI	Free	每天 1 万次神经元调用
Email Routing	Free	无限制转发规则
CDN + DNS	Free	无限流量（合理使用）
Analytics	Free	内置在 CDN 中
自定义域名	—	域名年费，与 Cloudflare 无关
后端总成本	¥0/月	真正的零成本后端架构

以前如果自建这些功能：一台轻量云服务器 ¥50/月，数据库 ¥20+/月，AI 模型部署 ¥100+/月，总计轻松破 ¥170/月。Cloudflare 把这些全部打到了免费档。

七、我没用到（但值得了解）的服务

服务	没用的原因
KV	D1 完全替代了键值存储需求
R2	博客媒体通过 GitHub 管理 + 图床，暂不需要对象存储
Pages	前端用 Vercel 部署，Next.js 在 Vercel 上体验更好
Durable Objects	博客没有强一致性实时协作场景
Vectorize	当前 AI 只有对话，还没有向量检索需求
Queues	消息队列对个人博客太重了

八、真实体验：优点与痛点

👍 让我心动的地方

零运维：不需要操心系统更新、防火墙、SSH 密钥、数据库备份策略
渐进增强：从 DNS 开始用，慢慢加 CDN → Workers → D1 → AI，每一步都是自然延伸
统一账单：所有服务在一个 Dashboard 里管理，不用记 5 个不同厂商的登录地址
开发者体验：wrangler CLI + wrangler.json 配置即代码，Git 管理一切
极致轻量：整个博客后端的依赖只有 @cloudflare/workers-types + postal-mime，没有 Express、没有 Prisma、没有 Redis

🤔 需要妥协的地方

调试体验：wrangler dev 模拟环境与实际部署有差距；wrangler tail 看日志总像隔了一层
冷启动：虽然 Smart Placement 改善了，但长时间无请求后首次访问偶尔会有顿挫感
D1 没有 Trigger：很多数据库事件驱动的逻辑无法用，不得不在应用层手动处理
平台锁定顾虑：理论上所有代码都是 Standard Workers 标准 API，但 D1 的查询方言和 Cloudflare 特有的绑定机制让迁移没那么无缝
本地开发依赖网络：虽然可以离线开发，但很多绑定（D1、AI）需要远程连接或模拟

九、架构反思：Cloudflare 解决的核心问题

回头看，引入 Cloudflare 之前我面临几个核心痛点：

痛点	Cloudflare 的解法
前端直接请求第三方 API 有跨域问题	Workers 做 BFF（Backend For Frontend），统一代理
第三方服务的 Token 不能暴露在前端	Token 全部存在 Worker 环境变量中
需要后端数据库但不想运维	D1 零运维，自动扩缩容
AI 功能需要模型部署	Workers AI 一行代码集成
想要自己的域名邮箱	Email Routing 免费搞定
流量统计不想用第三方	GraphQL Analytics API 直接取 CDN 数据

最后想说的

Cloudflare 最适合的场景是个人项目 / 小团队工具 / 轻量 API。它不是万能的，但在它擅长的领域里，提供了极其出色的开发者体验。

对我而言，选 Cloudflare 不是因为它是"最好的"，而是因为它让我用最小的成本验证想法、运行服务，把精力放在真正的产品逻辑上。

架构选择没有银弹，只有最合适的。

🌐 欢迎关注我的其他平台：

📧 联系我：mail@lxpavilion.top

posted @ 2026-07-27 16:30 PC2005-cloud 阅读(37) 评论(0) 收藏举报

刷新页面返回顶部

pc2005

选择cloudflare，给我的博客带来了什么

写在前面

一、基础层：DNS + CDN

1. 自定义域名 + DNS — 整个博客的基石

2. CDN + Cache API — 加速层

3. Cloudflare Workers — 后端底座

4. 后端代理 — 告别 Token 保留与 CORS 问题

三、存储层：D1 关系型数据库

5. Cloudflare D1 — 分布式 SQLite

四、服务层：邮件、AI 与分析

6. Cloudflare Email Routing — 邮件归档系统

7. Cloudflare Workers AI — 看板娘智能对话

8. Cloudflare Analytics API — 站点统计看板

五、优化层：加速与缓存

9. Smart Placement — 智能部署

六、账单：到底花了多少钱？

七、我没用到（但值得了解）的服务

八、真实体验：优点与痛点

👍 让我心动的地方

🤔 需要妥协的地方

九、架构反思：Cloudflare 解决的核心问题

最后想说的

公告