企业官网建设流程全解析

如果你把 Cloudflare 的文档页从头翻到尾，会发现没有任何一个页面写着“Cloudflare OS”这个词。但我这两年越来越多地用它这套边缘云能力搭产品，越来越觉得开发者圈子里其实早就存在一套被反复使用的架构模板——把 Workers 当 CPU，把 KV 和 Durable Objects 当内存状态，把 R2 当磁盘，把 Pages 当显示层，把 Zero Trust 当登录入口，组合起来就像一台部署在全球上千个边缘节点上、没有固定机房的操作系统。这就是这篇博文要聊的“Cloudflare OS”：一套基于 Cloudflare 全家桶的边缘应用承载方案。它能解决传统云架构里“机房远、冷启动慢、运维重”的痛点，适合做个人全栈项目、轻量 SaaS、协作类应用，也适合想抄一套低维护架构的独立开发者。

1. “Cloudflare OS”到底是个什么东西

1.1 从“用几个云服务”到“装一台云端机器”

很多人用 Cloudflare，是把它当 CDN 或 DNS 管理面板在用，顶多再挂一条 Workers 路由。但如果你把这些产品放在一起看，会发现它们的分工高度接近一台操作系统的各个子系统。

Workers 是执行指令的 CPU，每个请求进来都像发起一次进程调用；Durable Objects 是带状态、能锁资源的进程，负责做那些“全局唯一”“需要顺序协调”的事情；KV 是分布式缓存和配置中心，适合放需要快速读、不要求强一致的数据；R2 是对象存储，相当于磁盘，而且出口带宽不收钱，这点很多对象存储都做不到；D1 是内嵌的关系型库，适合放结构化业务数据；Queues 则是系统里的消息总线，用于异步任务解耦。

理解了这个映射关系，你再回头看“Cloudflare OS”这个概念，就不会觉得它是噱头。它不是官方产品，也不是某个开源项目的名字，而是一类架构设计的统称：把 Cloudflare 的各类边缘服务当作一套完整基础设施，去搭建一个本来可能需要一台 VPS、一套数据库、一堆中间件才能跑起来的应用。对我来说，这才是这套平台真正有价值的地方——运维面被压缩到极窄，你只需要关心业务代码和数据模型。

1.2 全家桶组件与“操作系统”对照表

下面这张表是我自己整理的一个映射，方便你做架构选型时快速对号入座。它不是严格意义上的同类对比，而是“在 Cloudflare OS 里大概扮演什么角色”的参考：

如果你觉得这套组合还是太抽象，可以把它想象成一台预装好的云电脑：Workers 是处理器，D1 是存储了业务表的内存数据库，R2 是那块存放图片和附件的大硬盘，Queues 处理后台任务，Access 是门禁刷卡机。相比自己租服务器再一层层搭建，这套东西的最大优势是“开箱即用”，并且每个组件都天然支持全球分布。

1.3 这套架构到底解决了什么问题

传统模式里，你想上线一个全栈应用，通常要经历：买云主机、配置系统环境、装 Nginx、部署数据库、弄 Redis、配 HTTPS 证书、再搭日志监控。哪怕用 Docker，也逃不开维护基础镜像、处理升级和漏洞的循环。而在 Cloudflare OS 这种思路下，你直接跳过整个“运营服务器”的阶段，因为代码从你写完 push 到生效，只需要一条 wrangler deploy 命令。

另一个被很多人忽视的收益是地理分布能力。普通云主机通常只能选几个地域的机房，跨区域用户访问延迟会明显升高。而 Cloudflare 默认就把 Workers 部署到离请求最近的节点执行，配合它自己的边缘缓存，全球用户的体验会均衡很多。这对个人开发者做面向海外用户的小工具非常有利，相当于花了单区域的价格，获得了一套自带全球分发节点的运行环境。

我之前有个小项目，用户分布在美国、欧洲和东南亚，以前放在一台欧洲 VPS 上，美国和亚洲用户反馈首屏明显偏慢。迁到这套结构后，静态资源直接走 Pages 边缘分发，API 由 Workers 在就近节点响应，没有额外改业务逻辑，体感上的速度提升非常明显。这个案例让我真正开始相信“边缘优先”不是口号，而是确实能降低用户可感知延迟的架构选择。

2. 核心设计思路与选型细节

2.1 计算层与“进程模型”的取舍

在 Cloudflare OS 里，Workers 是我们最常用的执行单元，它运行在 V8 隔离环境中，特点是非常轻量、启动快、并发高。但轻量也意味着它默认不能保存状态，同一个用户连续两次请求，Worker 的全局变量不会保留。为了在 Worker 里模拟“有状态进程”，就要引入 Durable Objects。

Durable Objects 可以理解为一组能在某个固定位置长期存活的对象实例。你通过一个唯一 ID 或名称绑定到它，它会保证所有对这个 ID 的请求都路由到同一个实例上。这个特性非常适合做实时协同、房间匹配、计数器、分布式锁一类需要“串行化”的逻辑。

选择 Work ers 还是 Durable Objects，我的判断标准很简单：如果逻辑只需要处理一个请求、不关心上一个请求留下的数据，就放 Workers；如果逻辑需要多个请求共享状态且对顺序敏感，就抽 DO。很多项目一开始全用 Workers，等做到“多个用户同时改一份数据”时才发现推倒重来成本很高。所以做架构时别说“后面再加状态”，得提前确定哪条边界上需要 Durable Objects。

2.2 状态与存储：KV、D1、R2 怎么分工

存储选型是 Cloudflare OS 设计里最容易出问题的一环，因为每个存储组件的特性差异很大。KV 简单好用，全球分布读起来很快，但它是最终一致性，写入之后可能需要几十秒甚至更久才能真正传播到所有节点。如果你做的是一个“写后立刻读同一份数据”的场景，比如用户刚更新完头像马上要看新头像，用 KV 就可能出现旧数据。

D1 是 Cloudflare 的关系型数据库，支持 SQL，适合放业务核心数据。D1 的数据持久性和一致性比 KV 好，但单库容量和性能上限需要规划，不能把它当成无限扩展的分布式数据库。我的做法是：业务主数据放 D1，热点只读数据再同步到 KV 做缓存，两边的数据同步通过业务代码触发或异步队列完成。

R2 则专心做对象存储，放图片、视频、静态文件。它的优势是兼容 S3 API，迁移成本低，而且出口流量不计费。在你不需要 CDN 缓存文件、只做存储和私有时，R2 比传统的对象存储更划算。需要注意，R2 也属于“按量付费”的服务，热数据频繁读取会产生请求费用，因此该套一层缓存的时候还是得套缓存。

2.3 入口与安全：Access 在整套架构里的位置

Cloudflare OS 的安全体系可以分成两层：第一层是平台自带的 WAF、速率限制、Bot 防护，用来拦截恶意流量；第二层是 Access，用来控制“谁能进入你的应用”。如果你做的是一个私有工具或者给少数客户使用的 SaaS 后台，直接用 Access 做身份层往往比自己写登录系统更省力。

Access 支持多种身份源，包括邮箱 OTP，你可以在不写一行代码的情况下，给整个域名或某个子路径加上登录校验。用户访问时，Cloudflare 会先要求验证身份，通过后才把请求转发到你的 Workers 或 Pages 应用。这就把认证逻辑从业务代码里剥离出去了，也意味着你的应用里可以少一个“用户体系”。

我建议所有个人开发者的管理后台都至少套一层 Access。因为很多 admin 页面没有复杂的权限设计，自己写很容易留下漏洞，而 Access 的配置是声明式的，维护成本几乎为零。真正要对具体用户做细粒度授权时，再在 Workers 里通过 JWT 或请求头拿到身份信息做二次判断。

2.4 为什么用“边缘优先”而不是保持传统架构

“边缘优先”不是所有场景的最优答案，但对个人开发者和中小团队来说，它是性价比极高的默认选项。因为你不需要预置服务器，不用担心流量突发打爆机器，不用凌晨爬起来处理 CPU 跑满的告警。边缘平台承担了弹性伸缩，你只需要关注函数执行时长有没有超过限制、成本有没有超出预期。

当业务需要原生 WebSocket 长连接、大量计算密集型任务、或者超低延迟内网访问时，传统 VPS 或专用服务器仍然有意义。但这类需求在个人项目里占比不高。大多数应用的本质是“存数据、取数据、渲染页面、处理用户输入”，而这些恰恰是 Cloudflare OS 最擅长的事情。

如果你已经有存量系统，迁移时也不用一步到位。可以先从静态资源迁到 Pages，再把少数读多写少接口迁到 Workers，最后再把涉及文件存储的部分切到 R2。灰度迁移的好处是每个阶段都能回退，风险可控。

3. 实操：从零搭一套“边缘云应用”

3.1 初始化项目与目录规划

我建议用官方 CLI 工具 wrangler 来初始化项目。常驻函数和页面放在一起时，可以采用 Cloudflare Pages + Functions 的模式，也可以单独拆一个 Workers 服务。就个人经验，如果你要做一个带后台管理的独立应用，直接用 Workers 包所有 API 更干净。

先安装依赖并创建项目：

npm create cloudflare@latest my-edge-os cd my-edge-os npm run dev

项目目录大致这样规划：

my-edge-os/ ├── src/ │ ├── api/ # 接口路由 │ ├── do/ # Durable Objects │ ├── storage/ # KV/D1/R2 封装 │ └── utils/ # 工具函数 ├── public/ # 静态资源 ├── wrangler.jsonc # 平台配置 └── package.json

这样的结构能保证后面加新功能时，不会所有代码堆在 index.ts 里。尤其当 Durable Objects、几个 Worker 脚本、队列消费者并存时，没有清晰目录层级，很快会陷入“这个文件到底在哪”的困惑。

3.2 用 Durable Objects 做一个多人协作草稿本

我先建一个 Durable Object 类，用来演示“有状态共享”的真实场景。很多教程都在讲它怎么做计数器，实际上它最有价值的地方是解决“两个人同时改一段文本”的问题。

下面的代码演示了一个非常简单的协作文档对象：

export class DraftRoom { private state: DurableObjectState; private content: string = ""; constructor(state: DurableObjectState) { this.state = state; } async initialize() { this.content = (await this.state.storage.get("content")) || ""; } async fetch(request: Request) { if (request.method === "GET") { return Response.json({ content: this.content }); } const body = await request.json(); this.content = body.content; await this.state.storage.put("content", this.content); return Response.json({ ok: true }); } }

注意构造器里不能直接读 storage，因为刚初始化的对象还没有恢复数据。更稳妥的做法是在 fetch 里先加载，或者通过 state.waitUntil 确保初始化逻辑完成。我在第一次写 DO 时就在这里踩了坑——构造器里读出来是空，害得我排查了半天。

把上面类绑定到路由后，在不同人的浏览器里编辑同一个页面，最终数据会收敛到同一个 DO 实例。它天然解决了“冲突只发生在同一份数据上下文”的问题，因为所有请求都落在同一份内存状态中。

3.3 用 KV 做全局配置中心

KV 很适合放“不经常变但到处要读”的全局配置。比如功能开关、站点标题、限流阈值等。相比传统数据库，KV 的读取延迟低，而且写代码时你不用关心连接池。

export async function getFeatureFlag(env: Env, key: string) { const cached = await env.FLAGS.get(key); if (cached) return cached; const value = await env.SECRET_CONFIG.get(key); await env.FLAGS.put(key, value, { expirationTtl: 60 }); return value; }

这个代码有两个细节：一是读 KV 时要注意 Key 的设计，建议加命名空间前缀，比如 navigation:menu、feature:chat，避免后续 Key 分散；二是设置 TTL 时把它当成缓存层，而不只是存储，因为 KV 天然有最终一致语义，不适合做事务型写入。如果你对实时性要求非常高，就想清楚能否接受短暂旧数据，不能的话换 D1。

3.4 用 R2 做附件上传与私有文件访问

R2 的 API 兼容 S3，所以你可以用官方的 AWS SDK 或 @cloudflare/r2 封装来操作，但更简单的方式是让 Workers 内直接通过绑定访问。

上传场景下，我习惯让客户端先请求一个预签名上传凭证，再由客户端直传 R2。这样文件不经过你的 Workers，减少了对函数 CPU 时间与内存的占用，长文件上传也不会把 Worker 拖得很久。

import { AwsClient } from "aws4fetch"; export async function createUploadUrl(env: Env, filename: string) { const r2 = env.MY_BUCKET; const client = new AwsClient({ accessKeyId: env.R2_KEY, secretAccessKey: env.R2_SECRET, service: "s3", region: "auto", }); const url = await r2.createPresignedUrl("PUT", filename, 600); // 也可以基于 client.sign 生成完整 URL return url; }

私密文件的读取建议走 Workers 中转鉴权，而不是公开 R2 URL。你先通过 Access 或自己的登录态校验身份，确认有权限后才从 R2 取文件返回，否则任何人都可能猜地址直读。公开静态文件则可以套一层 Cache API，或者直接绑到自定义域名再开 CDN 缓存。

3.5 接一个 AI 网关模块

Cloudflare 的 AI Gateway 可以用来统一管理多个模型厂商的 API，并提供缓存、限流和日志分析。对于个人产品来说，它最大的价值是让你不用在自己代码里处理“模型挂了切换备用 Key”的逻辑。

以下是一个最简单的接入示例：

export async function askAI(env: Env, prompt: string) { const res = await fetch("https://api.cloudflare.com/client/v4/accounts/{account_id}/ai/v1/gateway/{gateway_name}", { method: "POST", headers: { "Authorization": `Bearer ${env.AI_TOKEN}`, "Content-Type": "application/json", }, body: JSON.stringify({ model: "@cf/meta/llama-3-8b-instruct", messages: [{ role: "user", content: prompt }], }), }); return res.json(); }

我个人对 AI Gateway 的定位是“不让模型供应商锁死应用”。你可以先在网关后面接一个模型，后面想换模型时只调整配置，不用改业务代码。如果你做的是翻译、摘要、标签提取这类高重复请求功能，网关自带的缓存也能省一笔可观的模型调用费。

3.6 部署与绑定配置

本地开发没问题后，部署之前的配置集中在 wrangler.jsonc 中。典型配置如下：

{ "name": "my-edge-os", "main": "src/index.ts", "compatibility_date": "2025-01-01", "workers_dev": true, "bindings": [ { "type": "kv_namespace", "name": "FLAGS", "namespace_id": "..." }, { "type": "r2_bucket", "name": "MY_BUCKET", "bucket_name": "files" }, { "type": "durable_object", "name": "DRAFT_ROOM", "class_name": "DraftRoom" } ], "vars": { "API_NAME": "edge-os" } }

配置绑定至少要检查三点：KV namespace 是否已经创建、Durable Object 的 class 是否已导出、r2 bucket 是否存在。这三类资源如果没在控制台提前创建，wrangler deploy 往往会报“binding missing”之类的提示。我的习惯是先到仪表盘把资源全部建好，再写配置，而不是让 CLI 自动生成再改，这样可控性更强。

部署命令：

wrangler deploy

如果没有绑定自定义域名，Cloudflare 会给你一个 *.workers.dev 的域名。生产环境建议设置自定义域，并且把 Access 校验挂在前面。

4. 常见问题与调优实录

4.1 冷启动和响应延迟不对

很多人第一次调式 Workers 时说“接口总是慢”，最后发现不是代码慢，而是冷启动或路由问题。Workers 在请求较少时，会回收空闲的隔离环境，下一次请求需要重新加载代码。加载时间取决于代码体积和依赖数量。

优化方向有三个。第一，减少 npm 依赖，尽量使用原生 fetch 和 Web API；第二，把大模块改成动态导入，按路由拆分，而不是一个包全部塞进去；第三，对“非实时数据”开 Cache API，让后续请求直接命中缓存。

实际测试中，我的一个工具接口从 1200ms 降到 80ms，主要功劳就是缓存。对于静态内容或确定性输出，别让 Worker 每次都跑全套逻辑。

4.2 KV 的最终一致性让“写完就读”出现问题

使用 KV 最常见的坑：用户提交表单后，前端立即去读刚写入的数据，结果读到的还是旧值。原因是 KV 最终一致，写入操作会异步传播到所有边缘节点，你在写入了 A 节点的数据，可能在 B 节点读，B 还没同步到最新值。

解决思路有三种。如果这个“写后读”场景极其关键，数据本身放 D1，KV 只做前端加速；或者你接受短暂旧值，在 UI 上做乐观更新；或者你在写入后，主动请求同一个边缘节点，保证读与写落在同一区域（但这对跨区域用户不太现实）。

我的建议是：不要试图用 KV 构建强一致的功能。它就是一层缓存和配置面，真正的业务数据该放 D1 就放 D1，该放 DO 就放 DO。把 KV 当数据库用，最终代码会变得很难预测。

4.3 Durable Objects 创建速率受限

Durable Objects 并不是无限伸缩的。如果你在代码里每收到一个请求就 new 一个新的 DO ID，测压时很快就会遇到 429 之类速率限制。DO 的设计思路是长生命周期对象的复用，而不是短生命周期实例的快速创建。

比如一个协作文档房间，你按文档 ID 生成一个确定性的 DO ID，之后所有关于这个文档的请求都打进同一个 DO，这是最佳实践。如果每个请求都随机新开一个对象，那不仅性能差，还会快速消耗账号配额。需要控制并发时，可以在 DO 内部实现队列，或者用 Queues 做缓冲，而不是无脑创建对象。

4.4 R2 的计费远比想象中容易失控

R2 的出口带宽不收费，这确实很有吸引力，但请求次数和存储量是收费的。如果你做了一个图片上传应用，又没做任何缓存，那么用户每看一次图片就会产生一次 R2 读取，账单很容易悄悄涨上去。

正确做法是：公开读取的静态文件，最好挂在 CDN 缓存后面，让 Cloudflare 帮助拦截大部分重复请求；私有读取则按需回收连接，同时给文件设置合理的存储策略，比如定期清理过期附件。R2 还有一个 lifecycle 规则，可以自动删除旧文件，这能避免“只上传不清理”带来的存储费用。

4.5 本地调试与线上行为不一致

wrangler dev 默认在本地模拟大部分 Cloudflare 环境，但 KV、DO、R2 的行为在某些边界情况下和真实平台仍有差异。我遇到过本地跑得很顺，部署上线后 DO 的 storage 读取失败的问题，最后发现是因为代码在构造器里读了持久化状态——本地模拟环境比较宽容，真实环境则会在恢复状态前就进入请求。

调试技巧方面，我常用 wrangler tail 实时查看线上日志，它能看到请求是哪个路由、耗时多久、打印的日志是什么。另外，搭配 Sentry 之类的上报，在生产环境里把未捕获异常统一接住，比上线后焦虑地刷新仪表盘有效得多。

5. 这套架构还能怎么玩

做完上面这些基础组件，你会发现 Cloudflare OS 的能力边界远不止于“个人博客”或“API 转发”。因为计算、存储、数据库、对象存储、消息队列、身份认证都有了，你能组合出的产品形态非常多。

一个方向是 AI 应用。很多 AI 小工具本质上是“前端页面 + 模型 API 调用 + 结果缓存”，这正好是 Pages、AI Gateway、KV 的舒适区。你不需要部署任何 GPU 服务器，也可以做一个能处理高并发请求的 AI 翻译或摘要工具。

另一个方向是实时协作类应用。用 Durable Objects 做房间状态，用 Queues 做异步通知分发，用 R2 存协作中产生的附件。这个架构可以支持在线白板、文档协作、临时投票等玩法，而不必去维护一套 WebSocket 网关集群。

如果你有前端背景，还可以把很多“传统后端”的活儿全部外包给 Cloudflare 服务。第三方登录、Webhook 接收、定时任务，这些本来需要一台常驻服务器才能稳定跑的东西，现在都能用 Cron Triggers 和 Workers 实现，并且跟着全球边缘节点走，出了故障还会自动重新调度。

我自己接下来的几个工具型项目，大概率都会优先套用这套组合。因为踩过几轮坑之后，我发现这种架构能让我专注在需求本身，而不是半夜爬起来修服务器。做独立开发的人，最值钱的就是持续交付的时间和精力，把这些从运维中省出来，才是 Cloudflare OS 对我最大的价值。