如果你跟我一样，最近几年已经不太想在个人项目里养服务器，那你大概率听过一个说法：Cloudflare 不只是 CDN。我第一次意识到这一点，是在一个周末的下午——我躺在沙发上，用手机把一个博客仓库推到 GitHub，三分钟后新版上线，而整个过程没有碰过任何一台服务器的终端。那时候我就想，不如认真把这套东西拼起来，做成一个不需要 VPS、不需要续费提醒、也不需要半夜爬起来处理宕机告警的“个人操作系统”。我给这个组合起了一个糙名字：cloudflare-os。
这套组合并不是一个开源系统，也不是什么官方产品，而是把 Cloudflare 的 Pages、Workers、R2、KV、D1、Zero Trust 等托管服务串成一条完整的开发链路：代码托管在 Git 仓库，静态资源由边缘网络分发，业务逻辑跑在边缘函数里，数据落在云上的存储引擎里，后台管理用零信任网关保护。整体效果就像一台永远不会关机、也不用你打补丁的服务器，只不过它分散在全球三百多个数据中心里。
这篇文章写给三类人：一是嫌服务器贵、嫌运维烦的独立开发者；二是想用一套低成本方案把自己的项目“云原生化”的初学者；三是已经在用 Cloudflare 但总觉得它只是个加速工具、想榨干免费额度的人。我会按实际搭建顺序，把每一层怎么用、为什么这样选、踩过哪些坑都写清楚，你可以直接照着在自己账号里搭一遍。
1. 为什么我把 Cloudflare 当“操作系统”用
1.1 先说我原来的折腾路
在接触这套思路之前，我的个人项目大概是这么跑的：去云厂商买一台最低配的云服务器，装 Nginx，配 Let's Encrypt 证书，写 systemd 服务，加一个 UptimeRobot 监控，然后每隔一段时间处理一次证书过期、磁盘满了、进程被杀这种破事。
单个项目这么干还好，项目一旦变多，问题就出来了。每台服务器都要升级系统、修漏洞、备份数据；每个项目都要单独配置域名、反代、日志；新机器上线要重复一套流程，老机器下线还要担心数据没搬干净。最离谱的一次，我凌晨被报警短信吵醒，折腾到天亮才发现是隔壁项目的定时任务把磁盘写满了，顺带把我自己的博客拖死了。为这类事去运维一台服务器，真的不值。
后来我换了个思路：把自己的项目拆成两层——需要我自己维护的“服务器相关”东西，和真正需要我关注的“业务代码”东西。前者尽量外包给托管服务，后者才是我应该花时间的地方。cloudflare-os 就是把这种思路落到 Cloudflare 这个平台上，用它的免费托管能力，替我把“服务器相关”的部分全部吃掉。
1.2 Serverless 的真正含义
很多人听到 Serverless 第一反应是“没有服务器”，这个说法容易带偏。Serverless 不是没有服务器，而是你不关心服务器在哪里、是什么配置、谁在打补丁。它保证的是：只要你把代码部署上去，后面所有扩容、容灾、资源调度都是平台的事。
Cloudflare 的 Serverless 和传统云厂商还有一点本质区别：它不是在一个区域里给你一个函数实例，而是把代码推送到全世界三百多个数据中心边缘节点。用户在伦敦访问，代码就在伦敦附近的节点跑；用户在东京访问，代码就在东京附近的节点跑。用个不太恰当的比喻：传统云厂商是你在市中心开一家店，顾客都得跑来店里；Cloudflare 是连锁品牌搞中央厨房，食材配送到每个街区的橱窗，顾客走到哪里都能买到热乎的。这个“离用户近”的特点，对于一个强调响应速度的个人站点来说，价值比一台配置再高的单点服务器都明显。
当然，Serverless 不是万能的。它有超时限制、有冷启动、有平台绑定。所以我在整套方案里，只是把那些“无状态、事件驱动、读多写少”的任务交给它，真正需要长期占用内存、跑持续计算的东西，后面我会单独说边界在哪里。
1.3 cloudflare-os 各层到底提供什么
我通常把整套结构拆成四层：入口层、逻辑层、数据层、控制层。每一层在 Cloudflare 里都有对应的产品，组合起来就构成了一套完整的个人系统。
| 层级 | 对应服务 | 我拿它干什么 |
|---|---|---|
| 入口层 | Pages + 自定义域名 + CDN | 承载博客、文档站、落地页，负责静态资源分发 |
| 逻辑层 | Workers + 定时触发器 | 跑 API、做短链、处理表单、写爬虫、改写响应 |
| 数据层 | KV、R2、D1 | 存配置、存图片和文件、存结构化业务数据 |
| 控制层 | Zero Trust Access | 给后台页面和内部接口加一把登录锁 |
这套结构最舒服的一点是，我可以用一个域名把全部服务收纳起来：博客页面走 Pages，API 走单独的 Worker 路由，上传的图片走 R2，管理后台再被 Access 包一层。整台“云端机器”没有 IP 概念，没有 SSH 端口，没有我可以忘记打补丁的操作系统。对我来说，它就是一台互联网级别的个人电脑。
2. 入口层：用 Pages 把网站分发到全球
2.1 建站前唯一要做的准备
Pages 是 Cloudflare 的静态网站托管服务，也是整套方案的“门面”。它直接把一个 Git 仓库变成网站，每次推代码都会自动构建、自动发布、自动配 CDN，还免费送 SSL 证书。开始之前，你只需要做三件事：准备好一个 GitHub 或 GitLab 仓库、注册一个 Cloudflare 账号、把域名的 DNS 托管到 Cloudflare。
第三件事最容易忽略，但强烈建议做。如果你的域名 DNS 不在 Cloudflare，Pages 当然也可以绑定自定义域名，但要手工去域名商那里加 CNAME 记录，证书签发也要等一会儿。域名托管到 Cloudflare 之后，DNS 记录、CDN、证书、边缘缓存全部由一个控制台管理，绑定域名经常是点一下就自动完成的事情。
这里有一个判断标准：如果你只是做个临时演示页，用系统自动分配的.pages.dev域名完全够用；如果想当作正式项目长期对外提供服务，一定要绑定自己的域名。自动分配的预览域名一般只适合测试，正式项目用它既不体面也不利于后续迁移。
2.2 十分钟上线一个站点
以我现在搭建文档站为例，用的是 VitePress，操作步骤其实短到有点无聊：
- 在 Cloudflare 控制台进入 Pages 页面，点击“创建项目”，选择“连接到 Git”。
- 选择我的仓库，然后填写构建配置。VitePress 的构建命令是
npm run docs:build，输出目录填dist。 - 点击“保存并部署”，等待一两分钟，Cloudflare 会自动执行构建流程并生成一个
xxx.pages.dev的预览地址。
构建成功后，再从 Pages 项目设置里进入“自定义域”，添加我的域名。因为 DNS 托管在 Cloudflare，它会自动帮你加好解析记录，SSL 证书也是自动签发和续期。我实测下来，从执行git push到全站发布生效，一般三分钟左右。这个速度对一个静态站点来说已经非常舒服，改错东西直接再推一次就行，没有 SSH 上去改文件的环节。
如果你用的是 Hexo、Hugo、Next.js 这类框架，Pages 的后台预置了一堆框架预设，构建命令和输出目录绝大多数是自动填好的。只有极少数不走寻常路的框架需要手动调整，比如把 Node 版本从默认的 17 换成高版本的 Node 20。
2.3 预览环境和回滚：比想象中好用
Pages 有一个我很常用的能力：每次创建 Pull Request，它会自动生成一个独立的预览环境。你可以直接在 PR 的评论区看到预览地址，点进去就是这个分支构建出来的完整网站。团队协作时，不用先把代码合并到主分支才能看到效果；自己写博客也一样，可以在发布前用预览环境检查格式和图片是否正常。
回滚能力同样简单。Pages 的项目页面会保留每一次部署的历史记录，面板上有“回滚到此部署”的按钮。有一次我在新版本里把一篇还没写完的文章误发布了出去，点了一下按钮就回到上一个稳定版本，整个过程不到十秒，不需要抢救服务器文件，也不需要翻 Git 历史重新部署。
这一层最核心的经验是：把 Pages 当作你所有前端资产的默认目的地。它免费、快、带 CDN 和 SSL，还能回溯历史部署，个人项目用它几乎没有理由去买虚拟主机。唯一需要注意的是免费版每月有五百次构建配额，正常节奏的个人开发用不完，但如果你每天频繁试构建配置，这个额度就有点像“催你写对代码”的温柔提醒。
3. 逻辑层：Workers 让函数跑在用户旁边
3.1 最常用的几个 Workers 场景
Pages 负责静态内容，但一个现代个人系统不可能只有静态页面。你需要接收表单提交、做接口转发、生成 RSS、处理 webhook——这些任务交给谁？在 cloudflare-os 里，它们统一交给 Workers。
Workers 是 Cloudflare 的边缘计算平台，它用一个 JavaScript（或 WebAssembly）函数处理 HTTP 请求，部署后跑在全球数据中心。它的免费额度对于个人项目相当可观：每天十万次请求、每次请求最多支持一定量的 CPU 时间。基本上，日访问量几千的博客、API、工具站放在免费层都绰绰有余。
我自己用得最多的几个场景：
- 在旧站点和新技术栈之间做一层轻量转发，不改原站也能换新域名；
- 给博客加一个访客计数和一个“根据 User-Agent 返回不同内容”的接口；
- 做一个临时短链服务，不用自己去买跳转服务；
- 每天用定时触发器抓一次外部数据，校验后写入 KV。
其中最有代表性的是访客计数。它没什么价值，但极其能说明 Workers 的模型——读 KV 里的旧值、加一、写回、返回结果。整个过程没有数据库连接，没有进程管理，就是一个函数被边缘节点拉起、执行、结束。
3.2 一个能跑的计数器示例
下面是个最简化版本，绑定一个 KV 命名空间之后，就能实现一个全球部署的访客计数器：
export default { async fetch(request, env) { const key = "total_visits"; // 读取当前计数，拿不到就用 0 let count = Number(await env.MY_KV.get(key)) || 0; count += 1; // 写回计数 await env.MY_KV.put(key, String(count)); // 返回文本响应 return new Response(`第 ${count} 次访问`, { headers: { "Content-Type": "text/plain; charset=utf-8" }, }); }, }用wrangler.toml声明 KV 绑定：
name = "visit-counter" main = "src/index.js" compatibility_date = "2024-11-01" [[kv_namespaces]] binding = "MY_KV" id = "你创建的KV命名空间ID"然后执行npx wrangler deploy。部署完成后，访问那个workers.dev子域名，每点一次刷新，数字就会加一。
注意，这个写法在并发数量高的时候会丢计数——多个请求同时读到同一个旧值，各自加一后再写回，最后只会记录一次。真实生产环境里更靠谱的做法是用 Cache API 在前面扛住，或用 D1 的事务能力，甚至选择性地更新。个人博客量级无所谓，但你要理解这个模型的限制。
3.3 wrangler 调试心得
刚上手 Workers 时，很多人直接在网页编辑器里写代码，写完点部署，一旦报错就翻工。我自己的习惯是全用本地命令行调试：npx wrangler dev会起一个本地开发服务器，把外部的请求打进去，代码里的console.log会直接出现在终端。改完代码自动热更新，等本地确认没问题了再执行npx wrangler deploy推送。
线上日志用npx wrangler tail实时查看，这个命令会把当前 Worker 的所有请求和打印输出流到终端。排查线上问题时，先用它看日志，再去查代码逻辑，多数问题几分钟就能定位。我还养成了一个习惯：在关键分支里加上下文信息打日志，比如“请求路径、查询参数、上游返回状态”，因为 Workers 是分布式的，你在面板里看日志会看到多个数据中心交替出现同一请求，如果没有足够的上下文，很容易被一堆片段搅晕。
4. 数据层：R2、KV、D1 按需取用
4.1 三种存储的选择逻辑
写逻辑层必然会碰数据。Cloudflare 提供了三个存储产品，很多人分不清该用哪个，我把它们的适用场景放在一起比：
| 存储产品 | 适合场景 | 典型上限 | 一致性特点 |
|---|---|---|---|
| KV | 读多写少、低频更新的配置和全局状态 | 免费 1GB，每天十万次读 | 最终一致，写后约几十秒才会全球生效 |
| R2 | 图片、视频、静态文件等对象存储 | 免费 10GB，每月千万级读 | 强一致，像 S3 一样直接使用 |
| D1 | 需要 SQL、事务、关联查询的结构化数据 | 免费 5GB，每天百万行级读取 | 基于 SQLite，关系型模型，支持事务 |
最简单的判断口诀：数据是一张表，用 D1；数据是一大文件，用 R2；数据是一个 key 对应一个 value 且不要求实时，用 KV。选了 KV 却希望它像数据库一样强一致，是国内很多开发者第一次踩坑的地方。它适合存短链映射、主题配置、User-Agent 缓存这类“晚一分钟看到也没关系”的东西，不适合存订单、余额、投票结果。
4.2 不想买图床？用 R2 存图片
R2 是兼容 S3 协议的对象存储。为什么它对个人开发者这么友好？因为它的读取操作是完全免费的，没有按流量计费，意味着如果你把博客图片存在 R2 里，无论多少人刷图，都不会产生额外流量费。这一点和传统对象存储不同，传统对象存储经常是“存储便宜、流量贵”，个人站点一旦图片被人刷，月底账单就很酸爽。
我现在的做法是：博客里的所有图片直接打包上传到 R2 的一个桶里，通过一个绑定了自定义域名的 Worker 来读取，或者用 R2 自带的公共访问域名访问。日常用rclone就能把本地图片目录同步到桶里，操作和操作网盘差不多。免费额度 10GB 存储，对写博客存图来说，几年都不一定用得到一半。
同时 R2 支持 S3 API，这意味着你之前写过的任何 S3 兼容代码，改一下端点地址就可以直接迁过来，不需要重写业务逻辑。对于个人文件分享站、截图工具、小程序头像上传这类场景，R2 是一个很省钱的落点。
4.3 结构化数据的选择：我为什么把笔记数据放 D1
我以前喜欢把个人工具的配置放在 KV 里，后来发现要按时间排序、要按某列过滤时，KV 那套“按 key 精确读”的模型完全不顺手。于是把工具的配置表、访问记录、账单记录这类数据迁移到了 D1。
D1 是基于 SQLite 的关系型数据库，可以直接写 SQL 查询，支持事务。例如我要查“最近一个月哪篇文章访问量最高”，D1 里一行 SQL 就搞定，KV 就得把所有 key 都翻出来自己排序。更重要的是，在静态站构建时，我可以直接用 D1 的 API 拉取数据生成页面，再把页面缓存到 CDN，这就是一个完整的动态转静态流程。
它当然不是 PostgreSQL，单库规模不建议造太大，但个人工具的配置表、访问量统计、简单的 CMS 数据，都在它的舒适区里。顺便一提，D1 还支持从本地 SQLite 文件直接导入，我迁移旧项目数据的时候，导出 SQL 再导入到 D1，二十分钟就完成了。
5. 访问控制：用 Zero Trust 把后台锁起来
5.1 我的后台先被盯上的教训
部署在公开网络上的服务，迟早会被扫。我刚把自己的一个管理面板挂到云端时，没加任何访问控制，想着“反正没人知道这个地址”。结果不到两周，日志里就出现大量来自陌生 IP 的探测请求，试图访问admin、login、.env这些路径。虽然页面本身没有漏洞，但这种被“扒门缝”的感觉非常不好。
从那时起，我给所有带管理性质的后台都套上了 Cloudflare Zero Trust 里的 Access 服务。它本质上是一道前置登录墙：用户访问被保护的域名时，先进入一个认证流程，通过后才会被放行到真实页面。免费版最多支持 50 个用户，个人项目完全够用。
5.2 用 Access 做一个登录墙
在 Zero Trust 控制台里创建 Access Application，填好后台域名，然后选择登录方法。我一般选“One-time PIN”，也就是邮箱验证码：用户输入邮箱，收到一次性验证码，填写后即可进入。这个方式对个人项目来说成本最低，不需要维护额外的密码系统，邮箱就是身份。
如果要和朋友协作，可以配置登录方法里加上 GitHub、Google，也可以按邮箱后缀或 IP 段写访问策略。比如“只有@我的域名的邮箱可以访问所有内部页面，其他人只能访问不带数据的一个页面”，这些通过 Access Policy 就能实现。配置完成后，任何人没有通过认证，只会看到登录页面，连后端真实服务的面都见不到。
5.3 别小看审计和一次性访问
Zero Trust 的另一个价值是审计日志。谁在什么时间访问了哪个页面、用的是哪个邮箱，后台全部记录在案。多人协作时，这能避免“改坏了不知道是谁干的”这种扯皮。它还能生成临时访问链接，设定有效期后发给外部合作者，到期自动失效，不需要事后手动回收权限。
我在实践中形成的习惯是：凡是加了“管理”“控制台”“调试”字样的路径，一律套上 Access；凡是给人用但也需要身份的接口，套上更宽松但仍有认证的策略。这样即使在开放互联网上跑个人服务，心理负担会小很多。网络上的不确定性很多，能多一道官方登录墙就多一道。
6. 踩坑记录：这些坑我替你踩过了
6.1 Pages 部署成功但自定义域名打不开
这是我第一次用 Pages 绑域名时遇到的事。部署显示成功，但访问域名时报错，排查了很久发现是 DNS 记录冲突。因为早就有一条解析到别处的记录占用了同一个主机名，Cloudflare 无法自动添加新记录。
解决办法分两步：先在 DNS 设置里把旧记录删掉，再回到 Pages 的自定义域页面手动添加域名。如果你在域名服务商那边加了 A 或者 CNAME，而 Cloudflare 这边开启了 CDN 代理，还可能出现“记录在源站生效但代理没生效”的中间态。我的经验是：DNSSEC 根记录这种深水区先别碰，其余情况删干净记录、等一两分钟再重新添加，绝大多数能解决。
6.2 KV 缓存和实时性的摩擦
有一段时间我做一个站点的访问统计，把当天的浏览数写进 KV，页面读取展示。结果发现数值在几十秒内出现了回退，于是以为代码有 bug。后来查资料才知道，KV 是最终一致性模型，写入后会先在当前数据中心生效，再异步传播到全球其他节点，在传播完成前读取，可能拿到旧值。
从那以后我对 KV 的使用规则做了调整：只放“允许短期不一致”的数据，比如长期缓存、功能开关、短链映射。需要实时读写的数据一律改用 D1 或者在更新时直接用 Cache API 的purge清理缓存。你在做实时排行榜、计数器、在线状态这类功能时，别默认 KV 像内存变量那样即时。
6.3 别把 Workers 当常驻进程
很多人在第一次接触 Workers 时，会不自觉地把它当普通后端进程用：在全局变量里存连接池、在脚本启动阶段初始化长连接、在请求之外定时跑常驻任务。第一次部署忙一个小时，一访问却报错——因为 Worker 是无状态的，每次请求都是独立冷环境，全局变量不保证存活，连接池更不会在两次请求之间保留。
正确做法是把状态全部放到 KV、R2、D1 这些持久层，Worker 保持成一个纯函数：接收请求、读持久数据、计算、返回响应。脚本体积也别写过头，免费版的 Worker 脚本有大小限制，我遇到一个塞了很多第三方库的项目直接部署失败，最后修改配置才过，建议超过限制就拆成多个 Worker 用路由分发。定时任务用 Cron Triggers 触发没问题，但每个循环一定要注意 CPU 时间上限，死循环很容易直接把整个 Worker 打挂。
6.4 免费版和付费版的边界在哪
cloudflare-os 最大的吸引力是免费额度，但不能忽略边界。免费版适合原型验证、个人博客、日活几千的小工具；一旦你有可靠性的需求、更长的 CPU 执行时间、更大的存储，就需要升级到付费计划。我在项目上线初期一直用免费版，后来一个爬虫服务每天跑的任务量上来了，就升级到了 Workers Paid，按量付费并没有想象中贵。
这里特别提醒一句：Cloudflare 的免费额度参数一直在调整，不同年份、不同活动都可能不一样。动手之前先去官网看清对应的 pricing 页面，以账面上的额度为准。我上面提到的数字都只是“写这篇文章时的大致参考”，不值得作为长期决策依据。绑定信用卡可以解锁部分额度上限，但绑定前确认自动扣费规则，避免月底收到意外的账单。
最后聊聊这套系统的边界
前面花了大篇幅说 cloudflare-os 怎么把服务器给“消灭”掉，但你一定不要误会成所有项目都能塞进去。我自己保留了一台很便宜的 VPS，用来跑那些真正不能 Serverless 的东西：需要长时间占内存的任务、需要 WebSocket 长连接的服务、要跑本地进程的定时作业。Worker 再聪明也有 CPU 时间上限，Pages 再方便也不适合做实时音视频转码。工具是分层的，能在云上白嫖的绝不客气，白嫖不了的别硬上。
根据我自己的经验，起步阶段最简单的一条路是：先把博客或文档站迁到 Pages，把一个工具接口迁到 Workers，把一张数据表迁到 D1。等你在这一套流程里尝到“推代码就上线”的甜头，再逐步把其余业务搬过来。踩过几次坑之后，我更确信一件事——它确实不能替你解决所有问题，但它能把那些“原本必须自己扛的运维琐事”压缩到几乎为零，让你重新把精力放到业务代码本身。对我这种只会写业务逻辑、不想当运维的人来说，这就是 cloudflare-os 最大的价值。
