先提醒一句Cloudflare 官方至今没有发布过名为 cloudflare-os 的操作系统GitHub 上那个同名仓库也不是官方出品别被名字骗了。但这个词在开发者圈子里反复出现不是没有原因——它更像是一个代称用来描述 Cloudflare 全家桶组合起来的效果DNS、CDN、WAF、Pages、Workers、KV、D1、R2、Zero Trust 这些服务拼在一起几乎覆盖了一个传统操作系统能提供的所有功能位解析路径、缓存文件、执行进程、存储数据、管理权限。这篇文章不讨论那个仓库也不猜 Cloudflare 会不会做 OS而是从“把 Cloudflare 当操作系统用”的角度拆解这套体系怎么搭、怎么跑、哪里会翻车。适合想降低服务器维护成本、愿意拥抱边缘计算和 Serverless 架构的开发者参考。1. 先搞明白cloudflare-os 到底是个什么东西1.1 没有官方的 cloudflare-os但有完整的“服务版 OS”搜索 cloudflare-os你可能会看到一些开源仓库、技术博客甚至论坛热帖但不要指望它是一个类似 Ubuntu 的 Linux 发行版。真正有意义的是 Cloudflare 已有的那套分布式服务全球几百个城市的边缘节点当你把域名接入之后DNS 解析、缓存、安全过滤和边缘函数都在同一套体系里运转。对开发者来说这就像一个跑在互联网上的“系统”——不是装在你自己的机器里而是你的所有服务都跑在它上面你通过控制台和命令行去管理它。我习惯用一张映射表来记忆这套体系选型的时候直接套用Cloudflare 组件传统 OS 类比在项目里负责的事DNS / CDN路径解析 文件缓存域名接入、静态资源加速Pages应用商店/桌面托管前端页面Workers用户态进程业务逻辑、API、重定向KV内存键值缓存短码、配置、会话D1本地关系数据库结构化数据存储R2文件磁盘图片、附件、备份Zero Trust / Access内核权限管理登录鉴权、访问控制这个映射是我自己的理解不是 Cloudflare 官方定义但它在日常技术决策里非常有用当你遇到一个问题时先想想传统操作系统是怎么处理的再翻译成 Cloudflare 对应的组件即可。比如你要存用户头像传统方案是挂一块磁盘存文件对应到这套体系就是 R2你要存用户资料和文章传统方案是建一张 MySQL 表对应到这里就是 D1。1.2 为什么“当操作系统用”会成为趋势传统部署方式是这样的买一台 VPS装系统配 Nginx搭监控定期备份还要半夜爬起来处理安全补丁。而 cloudflare-os 的做法是把这些“系统维护”外包给一家公司你只需要关心业务代码和数据。尤其适合一个人或小团队维护的项目前端放 Pages接口放 Workers数据库用 D1 或 KV对象存储用 R2身份验证用 Access。这套组合最吸引人的地方是地域分布和硬件管理都被抹平了。不需要给数据库做高可用方案不需要操心某台服务器挂了Cloudflare 的全球网络替你承担了那部分复杂度。成本上也友好个人项目经常能压到接近零花费。但要注意它不是一个传统操作系统而是“服务组成的操作系统”它的边界不是安装路径而是每个组件的账单和配额。把这个底层逻辑想清楚了后面所有选型和排坑才有判断依据。2. 用 Cloudflare 全家桶搭一套“零服务器”服务栈2.1 先给每个组件定好职责搭建之前最重要的一件事是定职责否则很容易把 Workers 当万能膏药什么逻辑都往里塞最后调试起来非常难受。我的实践经验是静态资源包括 HTML、CSS、JS、图片放 Pages 或者 R2 的静态网站托管走 CDN 缓存。动态请求比如登录、上传、查询、表单提交全部走 Workers 处理的 API。配置类数据、短码映射、临时会话用 KV因为 KV 的读取速度很快适合读多写少的场景。结构化数据比如用户表、订单表、文章表用 D1因为这本质上是 SQLite走熟悉的 SQL 语法上手成本最低。大文件比如用户头像、视频、导出包用 R2因为它是 S3 兼容的对象存储而且没有出口带宽费这一点对个人项目特别重要。有个常见的误区是很多人把 KV 当成数据库用。KV 确实快但它最终一致写入后全球同步需要时间不适合做账务、库存这类对一致性要求高的数据。真正的强一致需求老老实实放 D1。选型的时候还有个原则能静态就不动态能边缘就不回源。比如一个博客的目录页如果内容变化不频繁完全可以让 Workers 把生成的 HTML 缓存起来而不是每次请求都查一次数据库省下的可是实打实的请求配额。2.2 案例搭一个轻量图床拿图床这个项目来拆解最直观。以前做一个图床需要一台服务器装一个后端框架配数据库、配 OSS/S3还要处理鉴权、防盗链工作量大得吓人。换成 cloudflare-os 这套体系之后架构长这样Cloudflare Pages负责上传页面和管理界面。Worker处理上传请求、读取请求、统计请求。R2存图片相当于磁盘设备。D1存图片的 key、大小、上传时间相当于本地数据库。KV存短码和访问次数的缓存应对高频读取。Access把管理后台保护起来只有自己能登录。上传接口的核心代码就非常短大概长这样export default { async fetch(request, env) { if (request.method ! POST) { return new Response(method not allowed, { status: 405 }); } const form await request.formData(); const file form.get(file); const key crypto.randomUUID() . file.name.split(.).pop(); await env.BUCKET.put(key, await file.arrayBuffer()); await env.DB.prepare(INSERT INTO images (key, size) VALUES (?, ?)) .bind(key, file.size) .run(); return Response.json({ url: https://img.example.com/${key} }); } };对应的 wrangler.toml 配置也足够简单name image-host main src/index.js compatibility_date 2024-01-01 [[r2_buckets]] binding BUCKET bucket_name my-images [[d1_databases]] binding DB database_name image-db database_id 你自己的数据库IDD1 的表结构用 SQL 初始化CREATE TABLE IF NOT EXISTS images ( key TEXT PRIMARY KEY, size INTEGER NOT NULL, created_at TEXT DEFAULT (datetime(now)) );这套方案跑起来之后我几乎没有为它操过心。图片上传就是一次 R2 写入加一次 D1 插入读取时 Worker 直接从 R2 返回二进制流图片量大了也不怕因为 R2 本身就是对象存储没有单机磁盘容量的概念。2.3 从域名接用到第一个部署的完整路径第一次上手不要把步子迈得太大先跑通一条最小路径。第一步是把域名接入 Cloudflare也就是改 NS 记录到 Cloudflare 给的两个地址等 DNS 生效控制台里能看到橙色云图标说明域名已经走代理。这是后面所有功能的基础CDN 缓存、WAF、Access 都要基于这套代理链路工作。第二步创建 Pages 项目。你可以连 GitHub 仓库自动构建也可以直接用命令行把静态文件推上去。我个人喜欢命令行部署因为不需要为了一个小页面专门建一个仓库。命令大致是这样npx wrangler pages deploy ./dist第三步部署 Worker。先建项目再登录账号然后本地预览最后发布npm create cloudflarelatest image-host -- --template worker npx wrangler login npx wrangler dev npx wrangler deploy发布成功后会得到一个*.workers.dev的域名调试特别方便。等一切都跑通了再去 Dashboard 里绑定自定义域名、创建 R2 桶、创建 D1 数据库并在 wrangler.toml 里把它们绑定到 Worker 上。初学者经常卡在绑定时容易搞混一个概念R2 桶、D1 数据库这些资源要绑定到 Worker 才能通过env.BUCKET、env.DB访问。绑定的关系是“Worker 到资源”的关联不是“域名到资源”的关联。我在早期就犯过这个错域名配置好了却忘了给 Worker 绑定数据库结果接口一直报 500查了半天才发现是绑定没加。3. 本地开发与联调命令行才是真正的系统桌面3.1 用 Wrangler 把本地变成边缘运行环境cloudflare-os 这套体系真正让我觉得“有操作系统体验”的地方是本地开发工具链。Wrangler 是官方 CLI它做的事情可以理解成在你电脑上模拟了一个小型的 Cloudflare 运行时。初始化项目、本地起服务、调 API、部署、查日志全部在命令行完成。我常用的命令也就那几个npx wrangler init my-project npx wrangler dev npx wrangler deploy npx wrangler d1 execute image-db --local --file./schema.sql npx wrangler secret put API_TOKEN这里要特别提一下wrangler dev的本地预览模式。它默认用最小化模拟器跑你的 Worker包括 KV、D1、R2 都有本地模拟版本数据存在项目目录下的.wrangler/state里。这意味着你可以离线开发不消耗任何线上配额改代码即时刷新效率非常高。3.2 本地环境与线上环境之间的差异不能只看表面本地跑通了不代表线上一定没问题因为本地模拟和真实边缘总有一些细节差异。我踩过最典型的一个坑是时间相关逻辑本地用的是电脑系统时间线上用的是 UTC 时间如果你在代码里用new Date().getHours()去判断“当前是白天还是晚上”在本地和线上可能得到完全不同的结果。另一个差异体现在资源读取上。本地wrangler dev默认连接的是模拟器但如果你用wrangler dev --remote它会连接真实的远程资源和线上 Worker 环境。联调阶段我通常先本地跑通逻辑再用--remote做一次真实性校验这样能发现本地模拟器里不存在的权限问题。本地开发还有个小技巧每次改完配置文件的绑定关系重启一下wrangler dev别让它自己热更新。因为热更新经常只重载代码不重载绑定关系造成“代码明明改了但绑定的 bucket 还是旧的”这种幻觉。3.3 密钥管理与多环境切换的实操套路每个正经项目都有密钥Cloudflare 的做法是让用户通过wrangler secret put把密钥上传到远程在本地则使用.dev.vars文件。这个文件的格式很简单就是键值对API_TOKENdev_value_only ADMIN_PASSlocal_debug_password记住一个关键点.dev.vars只对本地开发生效绝对不要和线上密钥混用。上传到远程的 secret 用npx wrangler secret put设置本地则用.dev.vars两者互不干扰。这样就能做到本地随便调试线上密钥不泄密。多环境切换方面早期 Wrangler 支持[env.production]配置块后来也有推荐用同一个账号下多个 Worker 名称做环境隔离的做法。我的习惯是测试环境用一个 Worker 实例生产环境用另一个 Worker 实例通过配置文件里的name字段区分避免误操作把测试流量打到生产库。毕竟这套体系最大的卖点之一就是低维护如果连环境隔离都没做好翻车一次花的精力会比省下的维护成本还多。4. 安全与访问控制这套 OS 的内核权限模型4.1 边缘侧的基础防护不用自己写代码把域名接入 Cloudflare 并打开代理之后你的站点就已经处在 CDN 和 WAF 的防护范围内这是自建服务器很难比的。最基础的三板斧是开启 Bot Fight Mode把常见爬虫和恶意机器人挡在源站之外。配置 WAF 自定义规则针对登录接口、上传接口做质询或拦截。配置速率限制规则比如同一个 IP 对/api/upload一分钟内最多请求 30 次。这些规则全部在 Dashboard 的图形界面上配置不需要写一行业务代码。对一个小团队来说等于免费获得了一个安全运维团队。需要注意免费套餐的 WAF 规则数量和自定义规则复杂度有限但常用场景已经完全够用。4.2 用 Access 把身份认证做在应用层之外Cloudflare Zero Trust 里的 Access 功能我的理解就是“内核权限模型”不用在你的应用代码里实现登录逻辑而是在边缘层把未认证的请求拦截掉。配置方式也很直接创建一个 Access Application指定要保护的域名和路径比如admin.example.com/*然后选择认证方式最简单的是 One-time PIN邮箱收到验证码后点击同意即可登录。这套方案对内部工具特别合适。我给自己的图床管理后台加了一层 Access 保护从此后台上不写任何登录代码想要进入管理页面先过 Cloudflare 的身份认证。代码里少了一块安全面也随之变小不用天天盯着有没有 SQL 注入、会话劫持这类问题。配合 Tunnel 使用更舒服。Cloudflare Tunnel 可以把本地跑的服务通过隧道暴露到公网不需要在路由器上开端口不需要公网 IP本地服务就自动获得了 HTTPS 和 Access 保护。我经常用它临时给客户演示一个本地原型演示完了直接关掉隧道非常干净。4.3 安全配置里最容易被忽略的三个坑第一隐藏 URL 不等于安全。有些人觉得把管理后台放在/manage路径下就没事了路径扫描工具很容易探测到。Access 保护的对象应该是整个应用或者至少是敏感路径前缀而不是靠“别人不知道这个地址”。第二缓存可能绕过你的鉴权。如果你的 Worker 对某个路径设置了缓存而缓存键里没有加上用户身份维度那么 A 用户请求得到的结果可能被 B 用户命中。尤其在放隐私数据时要么走 Access 保护要么在缓存规则里明确排除动态接口。第三WAF 规则表达式别写太宽。有人为了省事直接写了“所有 /api/ 请求都要质询”结果把自己前端页面请求的 Cookie 也质询掉了用户明明登录了却一直跳验证码。安全规则应该尽量细化到具体路径和具体行为宁可多写几条也别一刀切。5. 实际搬上这套体系之后我踩过的几个坑5.1 免费套餐真正受限的是资源边界不是功能很多文章喜欢罗列免费额度的具体数字但那些数字会随官方调整而变化参考意义有限。我更建议你关注这几个维度每日请求量、数据库读写量、存储占用、单次请求执行时间。个人项目前期流量不大通常都能压在免费额度内但一旦某个接口被爬虫盯上额度消耗速度会远超你想象。我的经验是在项目上线第一周就盯紧 Dashboard 的用量面板。比如 R2 桶的读次数是按操作类别计费的一个恶意脚本把你的图片接口遍历一遍额度立刻见底。应对方法也很简单给图片路径加签名参数或者配置缓存规则让绝大部分读请求直接命中 CDN不回源到 R2。别等账单邮件提醒才去处理那时候该超的早就超了。5.2 KV 的最终一致性坑了你多少次KV 的设计目标是全球分布式、低延迟代价是最终一致。也就是说你写入一个键值后可能过了几秒其他边缘节点才读到最新值。如果你用它来存用户刚修改的配置那么用户会体验到“保存了但没生效”的玄学现象。我后来养成了一个习惯凡是能接受短暂延迟的数据才放进 KV需要写后立读的数据放进 D1实在绕不过去的场景用 D1 做持久化KV 只做加速缓存。KV 不是 Redis它更像 CDN适合不经常变动的数据不适合当作高一致性状态存储这个认知能帮你少掉很多头发。5.3 Worker 冷启动和定时任务的两个现实问题Workers 的隔离模式决定了它有冷启动的可能。低流量个人项目的第一个请求经常会比后续请求慢几百毫秒这是资源回收后的正常现象不是代码写错了。优化思路有两个一是让 Worker 代码体积尽量小依赖越少启动越快二是在页面里用 Service Worker 或者预连接提示来掩盖延迟。说实话个人项目完全不用纠结这 300 毫秒真到了需要极致优化的时候你早就该换付费套餐了。定时任务方面Workers Cron Triggers 的调度粒度最小是一分钟秒级任务就别想了。如果你有“每 5 秒清一次 session”这种需求传统服务器还是更合适。另外定时任务触发时如果访问外部 API要自己处理超时和重试因为边缘执行环境的网络策略和你本机不一样不是所有公网地址都能直接访问。5.4 日志排障的体验和自建服务器完全不同自建服务器时你习惯 tail -f 日志文件很快能定位错误。搬到 cloudflare-os 之后日志散落在各个服务的 Trace 页面里免费方案里的日志保留期和处理深度都有限。一开始我很不适应后来学了两招。第一招在 Worker 里主动输出结构化日志带上请求 ID、业务错误码、关键参数而不是只console.log一行字符串。第二招本地优先复现。线上日志只告诉你哪里错了但定位根因最好还是在wrangler dev的本地环境里把代码改回去一步步跑因为本地可以加断点调试线上不行。这套组合拳虽然不能替代传统监控但对个人项目来说已经完全够用。5.5 D1 的边界比想象中窄选型前先想清楚D1 本质上是边缘托管的 SQLite它很好地解决了“不想维护数据库”这个痛点但别指望它能直接替代 PostgreSQL。SQLite 是单写者的模型虽然并发读没问题但高并发写入场景下会撞到锁限制。我的一个签到服务就是因为在同一瞬间大量写入出现了database is locked的报错后来通过把写入请求改为队列化处理才解决。另外D1 的查询语法还是要遵守 SQLite 的约束有些 MySQL 里的函数在 D1 里并不存在。迁移的时候不要直接导出 MySQL dump 灌进来那会报错到怀疑人生。更稳的做法是从第一天就确定数据结构是按照 SQLite 的规矩来设计的字段类型宽松匹配索引适度建立能避免后续大量踩坑。如果项目一开始就预见到复杂事务、高并发写、全套 SQL 兼容这些硬需求那就别硬套 D1用外部数据库加 Hyperdrive 也不是不行或者干脆回归传统服务器。6. 这套 OS 的边界在哪里哪些场景别硬上6.1 不适合的场景清单cloudflare-os 覆盖了很广的应用场景但它不是银弹有几种情况我不建议硬上。首先是 GPU 相关任务比如模型推理、视频转码这套体系里没有一个能直接跑 CUDA 的边缘计算单元。其次是超长任务比如一个 Worker 要跑十几分钟的数据批处理执行时间的硬限制会让它频繁失败。再次是强一致、高并发事务的需求D1 的 SQLite 模型在并发写入上不占优势非要硬写的话应用层要做很多妥协。还需要谨慎的是有状态长连接的大规模应用。Workers 支持 WebSocket但边缘函数天然是短暂存在的连接状态往往要借助 KV 或 Durable Objects 来管理复杂度会快速上升。如果你预见到项目核心就是一堆长时间维持的连接还是容器平台更顺手。6.2 与 Vercel、Fly.io、传统服务器的对比很多人会拿 cloudflare-os 和别的平台对比我给个大致的判断标准平台强项弱项Cloudflare 全家桶全球网络、安全层、边缘存储、低维护重计算和复杂状态场景受限Vercel前端托管体验极好、和 Next.js 深度集成后端能力相对单一存储弱Fly.io可以跑 Docker 容器、贴近传统后端需要自己搭建网络层和安全策略传统 VPS完全可控、任意技术栈、不限时长运维成本、故障恢复、安全补丁全自己扛从这个表可以看出来Cloudflare 的独特价值是“网络层和控制面的集成”。你的 DNS、CDN、WAF、身份认证、边缘函数都在同一个地方配置一次全局生效。Vercel 在前端体验上很优秀但它给不了你一个可以管理整条网络链路的控制台。Fly.io 可以跑任意容器但它不会帮你挡在边缘层做安全过滤。6.3 什么情况下应该选择回退传统服务器我自己的选择标准很简单当项目开始出现“资源绑定”和“物理资源”这两个词时就考虑回退。比如你需要挂载一个持久化磁盘来存大量文件需要调用 GPU 跑推理需要写一个常驻进程处理几万条 WebSocket 连接需要从系统层面做性能调优那么传统服务器或者容器平台会更合适。回退不代表全盘否定 cloudflare-os。我现在的做法是混搭静态资源和对外加速交给 Cloudflare核心 API 放在 Docker 容器里数据库根据需求决定放 D1 还是独立实例。先画一张组件映射表哪个组件用 Cloudflare哪个组件保留传统部署提前把这些边界理清楚比项目上线之后再重构要省事得多。我个人实际操作中的体会是cloudflare-os 的正确用法不是把它当成一个“替代服务器”的万能方案而是把它当成一套默认候选架构。拿到新项目先想想有哪些部分能天然享受边缘网络和托管服务的红利哪些部分必须保留传统计算资源。想清楚这两步整个项目就不会因为选型失误而陷入一边省钱一边填坑的困境。最后再分享一个小技巧无论项目多小都花半小时把 wrangler.toml 里的绑定、变量和环境隔离理清楚版本化的配置和代码一样重要这才是这套“操作系统”真正值钱的地方。 
长河君 · 2026/10/28 20:36:06 · 阅读 1.2k 把 Cloudflare 当操作系统用：零服务器架构的实践与避坑指南
先提醒一句Cloudflare 官方至今没有发布过名为 cloudflare-os 的操作系统GitHub 上那个同名仓库也不是官方出品别被名字骗了。但这个词在开发者圈子里反复出现不是没有原因——它更像是一个代称用来描述 Cloudflare 全家桶组合起来的效果DNS、CDN、WAF、Pages、Workers、KV、D1、R2、Zero Trust 这些服务拼在一起几乎覆盖了一个传统操作系统能提供的所有功能位解析路径、缓存文件、执行进程、存储数据、管理权限。这篇文章不讨论那个仓库也不猜 Cloudflare 会不会做 OS而是从“把 Cloudflare 当操作系统用”的角度拆解这套体系怎么搭、怎么跑、哪里会翻车。适合想降低服务器维护成本、愿意拥抱边缘计算和 Serverless 架构的开发者参考。1. 先搞明白cloudflare-os 到底是个什么东西1.1 没有官方的 cloudflare-os但有完整的“服务版 OS”搜索 cloudflare-os你可能会看到一些开源仓库、技术博客甚至论坛热帖但不要指望它是一个类似 Ubuntu 的 Linux 发行版。真正有意义的是 Cloudflare 已有的那套分布式服务全球几百个城市的边缘节点当你把域名接入之后DNS 解析、缓存、安全过滤和边缘函数都在同一套体系里运转。对开发者来说这就像一个跑在互联网上的“系统”——不是装在你自己的机器里而是你的所有服务都跑在它上面你通过控制台和命令行去管理它。我习惯用一张映射表来记忆这套体系选型的时候直接套用Cloudflare 组件传统 OS 类比在项目里负责的事DNS / CDN路径解析 文件缓存域名接入、静态资源加速Pages应用商店/桌面托管前端页面Workers用户态进程业务逻辑、API、重定向KV内存键值缓存短码、配置、会话D1本地关系数据库结构化数据存储R2文件磁盘图片、附件、备份Zero Trust / Access内核权限管理登录鉴权、访问控制这个映射是我自己的理解不是 Cloudflare 官方定义但它在日常技术决策里非常有用当你遇到一个问题时先想想传统操作系统是怎么处理的再翻译成 Cloudflare 对应的组件即可。比如你要存用户头像传统方案是挂一块磁盘存文件对应到这套体系就是 R2你要存用户资料和文章传统方案是建一张 MySQL 表对应到这里就是 D1。1.2 为什么“当操作系统用”会成为趋势传统部署方式是这样的买一台 VPS装系统配 Nginx搭监控定期备份还要半夜爬起来处理安全补丁。而 cloudflare-os 的做法是把这些“系统维护”外包给一家公司你只需要关心业务代码和数据。尤其适合一个人或小团队维护的项目前端放 Pages接口放 Workers数据库用 D1 或 KV对象存储用 R2身份验证用 Access。这套组合最吸引人的地方是地域分布和硬件管理都被抹平了。不需要给数据库做高可用方案不需要操心某台服务器挂了Cloudflare 的全球网络替你承担了那部分复杂度。成本上也友好个人项目经常能压到接近零花费。但要注意它不是一个传统操作系统而是“服务组成的操作系统”它的边界不是安装路径而是每个组件的账单和配额。把这个底层逻辑想清楚了后面所有选型和排坑才有判断依据。2. 用 Cloudflare 全家桶搭一套“零服务器”服务栈2.1 先给每个组件定好职责搭建之前最重要的一件事是定职责否则很容易把 Workers 当万能膏药什么逻辑都往里塞最后调试起来非常难受。我的实践经验是静态资源包括 HTML、CSS、JS、图片放 Pages 或者 R2 的静态网站托管走 CDN 缓存。动态请求比如登录、上传、查询、表单提交全部走 Workers 处理的 API。配置类数据、短码映射、临时会话用 KV因为 KV 的读取速度很快适合读多写少的场景。结构化数据比如用户表、订单表、文章表用 D1因为这本质上是 SQLite走熟悉的 SQL 语法上手成本最低。大文件比如用户头像、视频、导出包用 R2因为它是 S3 兼容的对象存储而且没有出口带宽费这一点对个人项目特别重要。有个常见的误区是很多人把 KV 当成数据库用。KV 确实快但它最终一致写入后全球同步需要时间不适合做账务、库存这类对一致性要求高的数据。真正的强一致需求老老实实放 D1。选型的时候还有个原则能静态就不动态能边缘就不回源。比如一个博客的目录页如果内容变化不频繁完全可以让 Workers 把生成的 HTML 缓存起来而不是每次请求都查一次数据库省下的可是实打实的请求配额。2.2 案例搭一个轻量图床拿图床这个项目来拆解最直观。以前做一个图床需要一台服务器装一个后端框架配数据库、配 OSS/S3还要处理鉴权、防盗链工作量大得吓人。换成 cloudflare-os 这套体系之后架构长这样Cloudflare Pages负责上传页面和管理界面。Worker处理上传请求、读取请求、统计请求。R2存图片相当于磁盘设备。D1存图片的 key、大小、上传时间相当于本地数据库。KV存短码和访问次数的缓存应对高频读取。Access把管理后台保护起来只有自己能登录。上传接口的核心代码就非常短大概长这样export default { async fetch(request, env) { if (request.method ! POST) { return new Response(method not allowed, { status: 405 }); } const form await request.formData(); const file form.get(file); const key crypto.randomUUID() . file.name.split(.).pop(); await env.BUCKET.put(key, await file.arrayBuffer()); await env.DB.prepare(INSERT INTO images (key, size) VALUES (?, ?)) .bind(key, file.size) .run(); return Response.json({ url: https://img.example.com/${key} }); } };对应的 wrangler.toml 配置也足够简单name image-host main src/index.js compatibility_date 2024-01-01 [[r2_buckets]] binding BUCKET bucket_name my-images [[d1_databases]] binding DB database_name image-db database_id 你自己的数据库IDD1 的表结构用 SQL 初始化CREATE TABLE IF NOT EXISTS images ( key TEXT PRIMARY KEY, size INTEGER NOT NULL, created_at TEXT DEFAULT (datetime(now)) );这套方案跑起来之后我几乎没有为它操过心。图片上传就是一次 R2 写入加一次 D1 插入读取时 Worker 直接从 R2 返回二进制流图片量大了也不怕因为 R2 本身就是对象存储没有单机磁盘容量的概念。2.3 从域名接用到第一个部署的完整路径第一次上手不要把步子迈得太大先跑通一条最小路径。第一步是把域名接入 Cloudflare也就是改 NS 记录到 Cloudflare 给的两个地址等 DNS 生效控制台里能看到橙色云图标说明域名已经走代理。这是后面所有功能的基础CDN 缓存、WAF、Access 都要基于这套代理链路工作。第二步创建 Pages 项目。你可以连 GitHub 仓库自动构建也可以直接用命令行把静态文件推上去。我个人喜欢命令行部署因为不需要为了一个小页面专门建一个仓库。命令大致是这样npx wrangler pages deploy ./dist第三步部署 Worker。先建项目再登录账号然后本地预览最后发布npm create cloudflarelatest image-host -- --template worker npx wrangler login npx wrangler dev npx wrangler deploy发布成功后会得到一个*.workers.dev的域名调试特别方便。等一切都跑通了再去 Dashboard 里绑定自定义域名、创建 R2 桶、创建 D1 数据库并在 wrangler.toml 里把它们绑定到 Worker 上。初学者经常卡在绑定时容易搞混一个概念R2 桶、D1 数据库这些资源要绑定到 Worker 才能通过env.BUCKET、env.DB访问。绑定的关系是“Worker 到资源”的关联不是“域名到资源”的关联。我在早期就犯过这个错域名配置好了却忘了给 Worker 绑定数据库结果接口一直报 500查了半天才发现是绑定没加。3. 本地开发与联调命令行才是真正的系统桌面3.1 用 Wrangler 把本地变成边缘运行环境cloudflare-os 这套体系真正让我觉得“有操作系统体验”的地方是本地开发工具链。Wrangler 是官方 CLI它做的事情可以理解成在你电脑上模拟了一个小型的 Cloudflare 运行时。初始化项目、本地起服务、调 API、部署、查日志全部在命令行完成。我常用的命令也就那几个npx wrangler init my-project npx wrangler dev npx wrangler deploy npx wrangler d1 execute image-db --local --file./schema.sql npx wrangler secret put API_TOKEN这里要特别提一下wrangler dev的本地预览模式。它默认用最小化模拟器跑你的 Worker包括 KV、D1、R2 都有本地模拟版本数据存在项目目录下的.wrangler/state里。这意味着你可以离线开发不消耗任何线上配额改代码即时刷新效率非常高。3.2 本地环境与线上环境之间的差异不能只看表面本地跑通了不代表线上一定没问题因为本地模拟和真实边缘总有一些细节差异。我踩过最典型的一个坑是时间相关逻辑本地用的是电脑系统时间线上用的是 UTC 时间如果你在代码里用new Date().getHours()去判断“当前是白天还是晚上”在本地和线上可能得到完全不同的结果。另一个差异体现在资源读取上。本地wrangler dev默认连接的是模拟器但如果你用wrangler dev --remote它会连接真实的远程资源和线上 Worker 环境。联调阶段我通常先本地跑通逻辑再用--remote做一次真实性校验这样能发现本地模拟器里不存在的权限问题。本地开发还有个小技巧每次改完配置文件的绑定关系重启一下wrangler dev别让它自己热更新。因为热更新经常只重载代码不重载绑定关系造成“代码明明改了但绑定的 bucket 还是旧的”这种幻觉。3.3 密钥管理与多环境切换的实操套路每个正经项目都有密钥Cloudflare 的做法是让用户通过wrangler secret put把密钥上传到远程在本地则使用.dev.vars文件。这个文件的格式很简单就是键值对API_TOKENdev_value_only ADMIN_PASSlocal_debug_password记住一个关键点.dev.vars只对本地开发生效绝对不要和线上密钥混用。上传到远程的 secret 用npx wrangler secret put设置本地则用.dev.vars两者互不干扰。这样就能做到本地随便调试线上密钥不泄密。多环境切换方面早期 Wrangler 支持[env.production]配置块后来也有推荐用同一个账号下多个 Worker 名称做环境隔离的做法。我的习惯是测试环境用一个 Worker 实例生产环境用另一个 Worker 实例通过配置文件里的name字段区分避免误操作把测试流量打到生产库。毕竟这套体系最大的卖点之一就是低维护如果连环境隔离都没做好翻车一次花的精力会比省下的维护成本还多。4. 安全与访问控制这套 OS 的内核权限模型4.1 边缘侧的基础防护不用自己写代码把域名接入 Cloudflare 并打开代理之后你的站点就已经处在 CDN 和 WAF 的防护范围内这是自建服务器很难比的。最基础的三板斧是开启 Bot Fight Mode把常见爬虫和恶意机器人挡在源站之外。配置 WAF 自定义规则针对登录接口、上传接口做质询或拦截。配置速率限制规则比如同一个 IP 对/api/upload一分钟内最多请求 30 次。这些规则全部在 Dashboard 的图形界面上配置不需要写一行业务代码。对一个小团队来说等于免费获得了一个安全运维团队。需要注意免费套餐的 WAF 规则数量和自定义规则复杂度有限但常用场景已经完全够用。4.2 用 Access 把身份认证做在应用层之外Cloudflare Zero Trust 里的 Access 功能我的理解就是“内核权限模型”不用在你的应用代码里实现登录逻辑而是在边缘层把未认证的请求拦截掉。配置方式也很直接创建一个 Access Application指定要保护的域名和路径比如admin.example.com/*然后选择认证方式最简单的是 One-time PIN邮箱收到验证码后点击同意即可登录。这套方案对内部工具特别合适。我给自己的图床管理后台加了一层 Access 保护从此后台上不写任何登录代码想要进入管理页面先过 Cloudflare 的身份认证。代码里少了一块安全面也随之变小不用天天盯着有没有 SQL 注入、会话劫持这类问题。配合 Tunnel 使用更舒服。Cloudflare Tunnel 可以把本地跑的服务通过隧道暴露到公网不需要在路由器上开端口不需要公网 IP本地服务就自动获得了 HTTPS 和 Access 保护。我经常用它临时给客户演示一个本地原型演示完了直接关掉隧道非常干净。4.3 安全配置里最容易被忽略的三个坑第一隐藏 URL 不等于安全。有些人觉得把管理后台放在/manage路径下就没事了路径扫描工具很容易探测到。Access 保护的对象应该是整个应用或者至少是敏感路径前缀而不是靠“别人不知道这个地址”。第二缓存可能绕过你的鉴权。如果你的 Worker 对某个路径设置了缓存而缓存键里没有加上用户身份维度那么 A 用户请求得到的结果可能被 B 用户命中。尤其在放隐私数据时要么走 Access 保护要么在缓存规则里明确排除动态接口。第三WAF 规则表达式别写太宽。有人为了省事直接写了“所有 /api/ 请求都要质询”结果把自己前端页面请求的 Cookie 也质询掉了用户明明登录了却一直跳验证码。安全规则应该尽量细化到具体路径和具体行为宁可多写几条也别一刀切。5. 实际搬上这套体系之后我踩过的几个坑5.1 免费套餐真正受限的是资源边界不是功能很多文章喜欢罗列免费额度的具体数字但那些数字会随官方调整而变化参考意义有限。我更建议你关注这几个维度每日请求量、数据库读写量、存储占用、单次请求执行时间。个人项目前期流量不大通常都能压在免费额度内但一旦某个接口被爬虫盯上额度消耗速度会远超你想象。我的经验是在项目上线第一周就盯紧 Dashboard 的用量面板。比如 R2 桶的读次数是按操作类别计费的一个恶意脚本把你的图片接口遍历一遍额度立刻见底。应对方法也很简单给图片路径加签名参数或者配置缓存规则让绝大部分读请求直接命中 CDN不回源到 R2。别等账单邮件提醒才去处理那时候该超的早就超了。5.2 KV 的最终一致性坑了你多少次KV 的设计目标是全球分布式、低延迟代价是最终一致。也就是说你写入一个键值后可能过了几秒其他边缘节点才读到最新值。如果你用它来存用户刚修改的配置那么用户会体验到“保存了但没生效”的玄学现象。我后来养成了一个习惯凡是能接受短暂延迟的数据才放进 KV需要写后立读的数据放进 D1实在绕不过去的场景用 D1 做持久化KV 只做加速缓存。KV 不是 Redis它更像 CDN适合不经常变动的数据不适合当作高一致性状态存储这个认知能帮你少掉很多头发。5.3 Worker 冷启动和定时任务的两个现实问题Workers 的隔离模式决定了它有冷启动的可能。低流量个人项目的第一个请求经常会比后续请求慢几百毫秒这是资源回收后的正常现象不是代码写错了。优化思路有两个一是让 Worker 代码体积尽量小依赖越少启动越快二是在页面里用 Service Worker 或者预连接提示来掩盖延迟。说实话个人项目完全不用纠结这 300 毫秒真到了需要极致优化的时候你早就该换付费套餐了。定时任务方面Workers Cron Triggers 的调度粒度最小是一分钟秒级任务就别想了。如果你有“每 5 秒清一次 session”这种需求传统服务器还是更合适。另外定时任务触发时如果访问外部 API要自己处理超时和重试因为边缘执行环境的网络策略和你本机不一样不是所有公网地址都能直接访问。5.4 日志排障的体验和自建服务器完全不同自建服务器时你习惯 tail -f 日志文件很快能定位错误。搬到 cloudflare-os 之后日志散落在各个服务的 Trace 页面里免费方案里的日志保留期和处理深度都有限。一开始我很不适应后来学了两招。第一招在 Worker 里主动输出结构化日志带上请求 ID、业务错误码、关键参数而不是只console.log一行字符串。第二招本地优先复现。线上日志只告诉你哪里错了但定位根因最好还是在wrangler dev的本地环境里把代码改回去一步步跑因为本地可以加断点调试线上不行。这套组合拳虽然不能替代传统监控但对个人项目来说已经完全够用。5.5 D1 的边界比想象中窄选型前先想清楚D1 本质上是边缘托管的 SQLite它很好地解决了“不想维护数据库”这个痛点但别指望它能直接替代 PostgreSQL。SQLite 是单写者的模型虽然并发读没问题但高并发写入场景下会撞到锁限制。我的一个签到服务就是因为在同一瞬间大量写入出现了database is locked的报错后来通过把写入请求改为队列化处理才解决。另外D1 的查询语法还是要遵守 SQLite 的约束有些 MySQL 里的函数在 D1 里并不存在。迁移的时候不要直接导出 MySQL dump 灌进来那会报错到怀疑人生。更稳的做法是从第一天就确定数据结构是按照 SQLite 的规矩来设计的字段类型宽松匹配索引适度建立能避免后续大量踩坑。如果项目一开始就预见到复杂事务、高并发写、全套 SQL 兼容这些硬需求那就别硬套 D1用外部数据库加 Hyperdrive 也不是不行或者干脆回归传统服务器。6. 这套 OS 的边界在哪里哪些场景别硬上6.1 不适合的场景清单cloudflare-os 覆盖了很广的应用场景但它不是银弹有几种情况我不建议硬上。首先是 GPU 相关任务比如模型推理、视频转码这套体系里没有一个能直接跑 CUDA 的边缘计算单元。其次是超长任务比如一个 Worker 要跑十几分钟的数据批处理执行时间的硬限制会让它频繁失败。再次是强一致、高并发事务的需求D1 的 SQLite 模型在并发写入上不占优势非要硬写的话应用层要做很多妥协。还需要谨慎的是有状态长连接的大规模应用。Workers 支持 WebSocket但边缘函数天然是短暂存在的连接状态往往要借助 KV 或 Durable Objects 来管理复杂度会快速上升。如果你预见到项目核心就是一堆长时间维持的连接还是容器平台更顺手。6.2 与 Vercel、Fly.io、传统服务器的对比很多人会拿 cloudflare-os 和别的平台对比我给个大致的判断标准平台强项弱项Cloudflare 全家桶全球网络、安全层、边缘存储、低维护重计算和复杂状态场景受限Vercel前端托管体验极好、和 Next.js 深度集成后端能力相对单一存储弱Fly.io可以跑 Docker 容器、贴近传统后端需要自己搭建网络层和安全策略传统 VPS完全可控、任意技术栈、不限时长运维成本、故障恢复、安全补丁全自己扛从这个表可以看出来Cloudflare 的独特价值是“网络层和控制面的集成”。你的 DNS、CDN、WAF、身份认证、边缘函数都在同一个地方配置一次全局生效。Vercel 在前端体验上很优秀但它给不了你一个可以管理整条网络链路的控制台。Fly.io 可以跑任意容器但它不会帮你挡在边缘层做安全过滤。6.3 什么情况下应该选择回退传统服务器我自己的选择标准很简单当项目开始出现“资源绑定”和“物理资源”这两个词时就考虑回退。比如你需要挂载一个持久化磁盘来存大量文件需要调用 GPU 跑推理需要写一个常驻进程处理几万条 WebSocket 连接需要从系统层面做性能调优那么传统服务器或者容器平台会更合适。回退不代表全盘否定 cloudflare-os。我现在的做法是混搭静态资源和对外加速交给 Cloudflare核心 API 放在 Docker 容器里数据库根据需求决定放 D1 还是独立实例。先画一张组件映射表哪个组件用 Cloudflare哪个组件保留传统部署提前把这些边界理清楚比项目上线之后再重构要省事得多。我个人实际操作中的体会是cloudflare-os 的正确用法不是把它当成一个“替代服务器”的万能方案而是把它当成一套默认候选架构。拿到新项目先想想有哪些部分能天然享受边缘网络和托管服务的红利哪些部分必须保留传统计算资源。想清楚这两步整个项目就不会因为选型失误而陷入一边省钱一边填坑的困境。最后再分享一个小技巧无论项目多小都花半小时把 wrangler.toml 里的绑定、变量和环境隔离理清楚版本化的配置和代码一样重要这才是这套“操作系统”真正值钱的地方。