用Cloudflare Workers搭建个人云OS：从VPS到边缘计算的实践指南

我一直觉得，"操作系统"这个词不该只属于电脑和手机。去年我给自己定了个挺折腾的目标：把我日常依赖的各种零散服务——笔记、书签、定时任务、临时文件、个人API——全部拼成一个能随取随用的个人云OS。调研了一圈之后，我把底座定在了Cloudflare上，项目代号就叫"cloudflare-os"。

这个项目说白了，就是用Cloudflare的边缘网络做"内核"，用Workers当"进程"，用KV、R2、D1这些存储当"内存和硬盘"。它解决的核心问题是：不想再为几个小应用维护一台服务器，也不想被各家免费服务割裂数据。如果你也受够了"为了一个博客、一个接口、一个定时任务各租一台机器"的状态，那这篇分享应该能给你一些实在的思路。

这个系列我会讲清楚三件事：为什么选Cloudflare而不是传统VPS，整个系统的架构怎么搭，以及上线后我踩过的坑。内容不追求大而全，就按我实际搭建的过程来。

1. 从"自建服务器"转向"边缘个人OS"的判断过程

1.1 自建服务器最难受的点不是钱，是"养"

很多人一想到个人云服务，第一反应是买台VPS。国内国外厂商都行，价格也确实不贵，一年几百块。但问题从来不在买，而在养。

我前前后后折腾过好几台VPS，最崩溃的一次是某天凌晨，一个运行了半年的服务突然挂了。查日志发现是磁盘满了，但明明没存什么东西，一排查是日志本身滚了十几个G。再往后又遇到内核升级后服务起不来的问题，那会儿我才意识到：维护一台服务器的隐性成本，根本不是那点租金的钱，而是你得持续投入时间去处理系统更新、安全补丁、进程守护、磁盘告警这些脏活。

有人会说，现在有各种PaaS平台，直接push代码就能跑。这话没错，但多数PaaS平台的免费层级要么有很严格的内存限制，要么会在30秒无请求后进入冷启动。真正用起来，你会发现一个尴尬的现实：很多个人应用其实是低频但需要随时可用的，比如凌晨的定时任务、偶尔打开的书签页、一个月用几次的文件转存。

1.2 Cloudflare对我的三个决定性价值

我对Cloudflare本身并不陌生，大多数用过博客的人都知道它是个CDN厂商，但真正让它变成"个人OS"底座的，是几个不太起眼的能力。

第一个是Workers的全球部署。你写一个JavaScript或TypeScript函数，它能自动分布在全球几百个数据中心。这对我这种没精力做多区域部署的开发者来说，直接省掉了一整块工程量。冷启动虽然存在，但在绝大多数个人场景下，基本感知不到。

第二个是存储生态的完整度。KV、R2、D1、Durable Objects，每个都有明确的适用场景。不需要像自建服务器那样先在数据库选型里纠结半天，一套API下来全打通。

第三个是Cron Triggers。Workers支持定时触发，免费的额度对个人项目来说基本够用。你那些"每天早上拉一次天气数据""每周备份一次书签"之类的需求，不需要再去单独搭一套定时任务系统。

当然，Cloudflare也不是没有缺点。比如Workers的运行时长限制，免费版CPU时间在10毫秒内（付费版可以放宽），这决定了你不可能在Worker里跑重型计算。还有，它的运行环境对包体积有要求，超过1MB就得自己想办法拆逻辑。我的做法是：能拆的拆成多个Worker，不能拆的推到R2里懒加载。

1.3 传统VPS和Free Plan的对比测试

在正式动手前，我花了一个周末做了次简单的对比测试。左边是我原来的一台1核1G的VPS，右边是Cloudflare的免费套餐。我部署了一个内容差不多的API服务，连续请求1000次测延迟。

结果很有意思：单次请求的响应速度，Cloudflare的免费套餐响应速度在某些区域反而比我的小型VPS更快，尤其是跨地区访问时。主要原因在于边缘CDN，请求直接就近命中了，而我的VPS只有单点。但在持续高负载的场景下，VPS的固定资源反而是稳定的，Cloudflare的免费层级如果触发了CPU时间限制，并发一高就开始报错。

这个测试让我彻底想明白了：Cloudflare适合的是"请求频率低、算力要求小、但必须全球快"的服务；VPS适合的是"持续重负载、需要完整环境"的服务。个人云OS，绝大多数组件属于前者。

2. 账号、域名与路由：整个系统最先要稳住的底盘

2.1 一个账号打底，免费套餐的边界在哪

注册Cloudflare账号，这里不多说了，一个邮箱就行。我用的免费套餐，没有单独开付费计划。很多人问免费的够不够用，我的回答是：够用，但要知道边界。

免费套餐里，Workers有每天10万次请求的额度，KV有每天10万次读、1000次写，R2的存储免费额度是10GB，D1数据库是每天500万行读。这些数字对个人项目来说，绝大多数时候没法触顶。真正需要留意的反而是Worker脚本的CPU时间限制：免费用户每次运行CPU时间不能超过10ms（免费层这里是10毫秒CPU时间，不是请求时长）。如果你有复杂的运算，干脆把任务拆成多个步骤，或者用Queue异步处理。

2.2 把域名接入Cloudflare的全流程

域名接入这部分，看起来简单，但有几个细节我一直提醒自己注意。

如果你是在Cloudflare新注册的域名，跳过添加站点的步骤，直接就能在DNS面板配置。如果是外部域名，流程是：先把域名的NS记录改到Cloudflare指定的两个NS地址，然后等生效。生效之后，你有两种方式让Worker跑在你的域名下：一是给Worker绑定自定义域名（Custom Domain），二是通过Route（路由）把某个子域名的请求转发到指定Worker。

我自己用的是Bound Custom Domain方式。原因是直观且不容易和DNS记录冲突。比如我的笔记服务绑定的是note.mycloud.dev，书签服务绑定的是bookmark.mycloud.dev，直接在Worker的域名配置里加上就能用，Cloudflare会自动创建对应的DNS记录。

2.3 路由规划决定了你后面运维省不省心

路由规划是整个项目里我觉得最值得花时间想的事。很多人的习惯是建一个Worker，然后把所有业务逻辑塞进同一个脚本里，路由靠URL判断。这在项目初期看起来挺顺，但一旦业务多起来，你会发现：改一个功能必须重新部署整个脚本，一个模块出bug可能导致所有服务不可用。

我的做法是"一业务一Worker"。每个Worker只管一件具体的事，比如feed-parser只负责抓RSS，image-resizer只处理图片缩放，todo-api只暴露待办接口。然后通过Cloudflare的路由规则，把不同子域名的请求分发到对应Worker。这样每个Worker都是独立部署、独立回滚，出了问题也只会影响一个功能。

这里还有一个经验：把子域名的命名规则定清楚。我用的格式是"功能名.主域名"，一眼就能看出是干什么用的。像auth.mycloud.dev这种做登录鉴权，file.mycloud.dev做文件上传下载。后面接第三方回落机制的时候，也比一个裸域到处转发清晰得多。

3. 个人OS的存储层选型：KV、R2、D1、Durable Objects怎么配合

3.1 四种存储的定位差异

Cloudflare的生态里最唬人的就是存储产品多，KV、R2、D1、Durable Objects。很多人一开始会问，到底用哪个？我直接给了自己一张对照表，按场景选型，不纠结：

我最早犯的错误是把KV当数据库用。往里塞了一堆结构化数据，结果要做列表查询时完全无从下手。KV的价值是"用key直接拿value"，如果业务逻辑里有"按条件筛选"这种需求，KV不是合适的选择。

3.2 各存储在小项目里的真实提质经验

先说KV。我拿它做了两件事：一是存全局配置，比如不同服务的开关状态和API Key的加密串；二是做短链接服务里的URL映射。效果非常好，读延迟几乎可以忽略。KV的注意事项是写入后的生效延迟。虽然是最终一致性，但实测通常几十毫秒内就能读到新值，对个人项目不影响。

D1是最让我惊喜的一个。之前我一直没想到Cloudflare会推出SQLite兼容的关系型数据库。我现在把待办清单、书签的分类和标签关系、以及RSS阅读状态都存在D1里。因为SQLite的语法很接近传统数据库，我几乎没花学习成本。唯一要注意的是D1的连接方式，如果你在Worker里每次请求都新建连接，很容易把连接数打满。官方推荐的是在Fetcher里复用连接。

R2的定位就简单了，存文件。我主要存两类：图片资源和定时备份的压缩包。R2支持S3 API，所以如果你熟悉AWS S3的SDK，直接把endpoint换成R2的地址就能用。这里有必须注意的一点：R2的公开访问默认是关闭的，如果你直接用URL去访问Bucket里的资源，会得到AccessDenied。要么通过Worker做一层鉴权和转发，要么在R2的Bucket设置里绑定自定义域名。

Durable Objects我目前只在一个场景用了：多人协作的Markdown白板。因为它支持WebSocket的持久连接和单点状态，比用KV+轮询舒服得多。但它也是最容易被"过度使用"的存储类型，官网文档明确说它适合有状态的服务，如果只是存个数据，别用它。

3.3 一个完整的存储方案配置示例

我直接贴一段我项目的初始化代码，帮大家把概念落到实践。

比如我要在Worker里同时用D1和KV，wrangler.toml是这么配置的：

name = "cloudflare-os" main = "src/index.js" compatibility_date = "2025-01-01" [[d1_databases]] binding = "DB" database_name = "my-os-db" database_id = "xxxxxxxxxxxx" [[kv_namespaces]] binding = "MY_KV" id = "xxxxxxxxxxxx"

然后在Worker脚本里：

export default { async fetch(request, env, ctx) { // KV读配置 const theme = await env.MY_KV.get('theme'); // D1查询 const { results } = await env.DB.prepare( 'SELECT * FROM bookmarks WHERE status = ?' ).bind('active').all(); return new Response(JSON.stringify({ theme, results }), { headers: { 'content-type': 'application/json' } }); } }

这样就同时接入了两个存储，后面扩展R2也类似，只需要再加一个binding声明。

4. 端到端搭建：从域名到第一个Worker应用跑通全流程

4.1 本地环境准备：Wrangler CLI的安装

Cloudflare官方提供的命令行工具叫Wrangler，所有项目的本地开发、上传、日志查看都靠它。安装很简单，Node环境前提下用npm:

npm install -g wrangler

装完之后先登录：

wrangler login

它会自动打开浏览器让你授权。这一步必须做，不然后面没法部署。如果是在无浏览器环境，可以用wrangler login --api-key方式手动填Token，但我不太推荐，容易把Token留在shell历史里。

4.2 创建一个Worker并绑定额外资源

执行wrangler init cloudflare-os，它会帮你生成一个基本的Worker项目结构，包括wrangler.toml和src/index.js。

我习惯在index.js里先用一个最简单的响应测试连通性：

export default { async fetch(request, env, ctx) { return new Response('cloudflare-os running'); } }

然后直接部署：

wrangler deploy

部署完成后，你会得到一个xxx.workers.dev的地址。打开浏览器看一下，如果能看到那行文字，说明环境OK。

接着把之前配置的D1和KV绑定好，重新部署一次。到这一步，你的Worker已经具备读写数据库和缓存的能力了。

4.3 绑定自定义域名与HTTPS配置

我个人不建议长期使用*.workers.dev域名，一是因为部分网络环境对这个域名有屏蔽风险，二是不符合"个人OS"的统一感。绑定自定义域名的方式分两种：

第一种，在Cloudflare控制台的Workers页面，选择你的Worker，进入Settings -> Domains -> Add，然后输入你想绑定的子域名。系统会自动创建一条DNS记录，生效时间通常在几分钟内。

第二种，在wrangler.toml里指定route配置，例如：

routes = [ { pattern = "note.mycloud.dev", custom_domain = true } ]

custom_domain = true表示它是直接绑定而不是通过代理路由，配置完执行wrangler deploy就行。

HTTPS方面，绑定到Cloudflare域名下的Worker会自动启用HTTPS，不需要自己配置证书。这是我特别喜欢的一点，在其他平台，光是一个证书续期就能消磨掉人的耐心。

4.4 跑通定时任务：Cron Triggers的完整配置

个人OS里，定时任务是最能体现"自动运行"魅力的部分。Cron Triggers在wrangler.toml里配置：

[triggers] crons = ["0 0 * * *", "30 8 * * *"]

第一行表示每天零点触发，第二行表示每天早上8点30分触发。时间默认是UTC，如果要按北京时间，需要换算：北京时间比UTC快8小时，所以"每天早上9点"对应的cron应该是"0 1 * * *"。

在Worker脚本里，你要监听scheduled事件：

export default { async scheduled(event, env, ctx) { // 根据event.cron判断当前执行的是哪个任务 if (event.cron === '0 0 * * *') { await runDailyBackup(env); } if (event.cron === '30 8 * * *') { await fetchMorningNews(env); } } }

一个Worker可以绑定多个cron表达式，你在代码里通过event.cron区分具体执行哪段逻辑。跑完之后，可以到Cloudflare的日志面板看一眼输出，确认没有异常状态。

5. 上线后的真实体验与常见坑

5.1 免费套餐里最容易触碰的隐形限制

项目上线一个月后，我开始遇到一些奇怪的现象：某个接口突然返回523或者524。排查发现不是代码问题，而是我在处理图片时开了ctx.waitUntil()执行一些不紧急的后台任务，导致Worker实例占用的总时长超过了免费额度。

这里需要说清楚区别：Worker的免费套餐是"每天10万次请求"不假，但每次请求你可以跑的时间不是无限。CPU时间限制是一个，杀手锏是"实例内存限制"。如果你的Worker实例运行时间超过30秒，不管你是在等待上游接口还是处理大文件，都会被杀掉。对个人项目来说，建议把凡是可能超过10秒的任务都改成异步队列。

另外，KV免费额度里"每天1000次写"听着少，但对你个人使用还好。如果你一时想不开，用KV记录每条用户日志的递增计数，那很快就会爆表。我当时就因为这个把一天的写额度耗尽过，整体心路历程十分崩溃。建议所有写操作推量级时，先在配置里加一层开关或采样率。

5.2 日志监控的几个实用命令

每次部署完，我都习惯用两条命令看运行情况：

wrangler tail --format pretty

这个是实时打印线上日志，排查问题非常有用。它会一直挂着监听，直到你Ctrl+C退出。适合在部署后立刻跑一遍，确认没有报错。

如果你想看历史日志，使用wrangler tail --status会有点不太够用。我一般直接去Cloudflare后台的Workers -> 对应Worker -> Logs页面查看。注意免费套餐的日志只保留一小段时间，所以出问题时尽快看。

5.3 缓存与数据不一致的两个实测场景

由于有CDN这个中间层，Cloudflare的缓存策略很多情况下能帮你大幅加速，但也容易踩坑。

第一个坑：静态资源的更新滞后。我一开始把图片存在R2，然后通过Worker返回。当时给响应设了Cache-Control: public, max-age=3600，结果换了一张头像，但一小时内所有访问者看到的都是旧图。后来我把需要即时更新的资源改成no-cache，或者上传时把文件名加上版本号，彻底解决。

第二个坑：D1数据的跨区域读。D1默认在主区域写入，其他区域需要复制和同步。有一次我在某地中心机房附近调试，写入一条待办，立刻从另一个区域请求，结果没读到。后来又过一个几秒，再请求才出现。这个现象符合预期，毕竟D1的强一致是多区域副本同步后才能做到。解决方案是：关键数据立即回读时，直接强制请求写入区域，或者应用里做一个短时间的本地缓存补偿。个人场景不用太纠结，正常使用基本无感知。

5.4 免费套餐部署环境的兜底思路

有人会担心，万一Cloudflare某个服务出问题，个人OS是不是就全瘫了？我现在的做法是：把最核心的几个Worker，比如保存了重要数据的API，另加了一个备份方案。每天定时通过Cron Triggers把D1的表导出成JSON，存到R2。然后R2里的备份文件，再用Cron推到另一家对象存储（随便选个免费额度够用的就行），实现离岛备份。这样就算Cloudflare后台临时不可用，至少数据不会丢。

这套方案的代价是每天多了两次API调用，几乎可以忽略。但对"个人OS"来说，数据安全永远比功能多寡优先级更高。

6. 实际项目的完整代码布局

6.1 多Worker项目结构参考

整个cloudflare-os项目我最终调整成了monorepo结构，一个仓库管理所有Worker，每个子目录独立部署。结构是这样：

cloudflare-os/ ├── workers/ │ ├── auth-api/ # 登录鉴权 │ ├── bookmark-api/ # 书签管理 │ ├── note-api/ # 笔记管理 │ ├── file-api/ # 文件上传下载 │ ├── cron-tasks/ # 定时任务集合 │ └── short-link/ # 短链接服务 ├── packages/ │ └── shared-utils/ # 公共方法，比如加密解密、日期格式化 ├── scripts/ │ ├── deploy-all.sh # 批量部署脚本 │ └── backup-db.sh # 数据库备份脚本 └── wrangler.toml # 各Worker的配置，可以用include的方式拆开

每个Worker的入口文件都保持极简，核心逻辑抽到共享包或独立模块里。这样做的最大好处是：以后要引入测试，改造某个模块时不会影响其他服务。

6.2 核心Worker的代码片段

这里贴一段我书签API里最有代表性的代码，完整展示如何同时用D1和R2。书签的数据放在D1，书签缩略图的截图文件放在R2。

export default { async fetch(request, env, ctx) { const url = new URL(request.url); const path = url.pathname; // 增删改查的REST路由 if (request.method === 'GET' && path.startsWith('/api/bookmarks')) { const { results } = await env.DB.prepare( 'SELECT * FROM bookmarks ORDER BY created_at DESC LIMIT 100' ).all(); return Response.json(results); } if (request.method === 'POST' && path === '/api/bookmarks') { const body = await request.json(); const key = `bookmark-${Date.now()}`; const imgKey = `thumb-${key}.png`; // 将截图存入R2 if (body.screenshotBase64) { const imgBuffer = Buffer.from(body.screenshotBase64, 'base64'); await env.FILES.put(imgKey, imgBuffer, { httpMetadata: { contentType: 'image/png' } }); } await env.DB.prepare( 'INSERT INTO bookmarks (title, url, thumb_key) VALUES (?, ?, ?)' ).bind(body.title, body.url, imgKey).run(); return Response.json({ ok: true, key, imgKey }); } return new Response('Not Found', { status: 404 }); } }

通过这段代码你会发现，整个流程并没有比传统服务器开发复杂多少，但部署和运维的体验完全不在一个量级：没有SSH，没有systemd，没有Nginx配置。

6.3 用Queue处理重任务的优雅方案

前面提到Worker的执行时长限制，这让我开始用Queue来解耦重任务。Cloudflare的Queues产品可以当作一个简单的消息队列，Worker把耗时操作的消息放进去，另一个Worker作为消费者来处理。

图示就不画了，用文字描述流程：用户上传图片 -> 入口Worker把"图片处理"的消息塞进Queue -> Queue触发图片处理器Worker -> 处理器从R2拉原图 -> 生成缩略图 -> 存回R2 -> 更新D1记录。整个过程中，入口Worker只负责快速响应"已收到"，处理在后台异步完成。

这个设计让我的文件服务不再受30秒限制，实测上传一个5MB的图片，接口响应时间稳定在200毫秒左右，而之前直接在Worker里做缩略图时经常超过1秒。

7. 一套没有服务器却无比顺手的个人服务形态

项目上线到现在已经跑了几个月，给我最大的感受倒不是省了多少钱，而是心理负担轻了很多。以前用VPS时，我总有一种"后院需要浇水"的焦虑，每次系统发安全公告都要盘算要不要升级。现在，升级这种事Cloudflare在后端就处理完了，我要做的只是重新部署一下Worker代码。

日常使用中，我的所有数据入口都收敛在这套系统里：手机上的快捷指令通过Webhook写D1，电脑上的浏览器插件直接调API，平时写文章用的Markdown图片全部传到R2，再通过Worker统一输出成可访问链接。最奇妙的一点是，这套架构天然就是分布式缓存，在各地机房都有响应点，比我以前任何一台VPS都快。

回到"cloudflare-os"这个名字，它本质上一个比喻，把我所有的数字生活挂靠在一套统一的运行时环境上。如果你也想折腾，我给的建议很朴素：从小做起，先跑通一个API，再逐步加存储和定时任务。千万不要一上来就想着把全部业务搬上去，那只会让你在第一天就被配置项淹没。每天推进一点点，"OS"会在周末前悄悄长成。