Cloudflare Workers 入门到选型：部署步骤、费用公式、限制与组件组合
简答：一句话回答：Cloudflare Workers 是运行在 Cloudflare 网络上的边缘函数平台，适合 API、Webhook、鉴权、缓存、轻量 SSR 和异步编排。最快入门流程是安装 Node.js 与 Wrangler，运行 `npm create cloudflare@latest` 创建项目，再用 `npx wrangler dev` 本地测试、`npx wrangler deploy` 发布。若你需要完整 Node.js、长时间后台进程、操作系统级控制或持久本地文件，应优先比较 VPS、容器、AWS Lambda、Vercel Functions 或 Deno Deploy。本站不是 Cloudflare 官方站；代码、运行时、价格和账户配置以 Cloudflare 当前文档为准，本文重点补充部署后的访问、DNS、延迟、丢包和连接排查边界。
定义：Cloudflare Workers 是基于 V8 isolates 的托管边缘运行时：请求到达 Cloudflare 网络后，由 Worker 的 `fetch(request, env, ctx)` 处理器执行代码，并通过绑定访问数据库、对象存储、队列和持久化状态服务。
先看结论：30 秒判断 Workers 是否适合你
优先考虑 Workers：你要部署全球 API、Webhook、鉴权、反向代理、缓存逻辑、边缘重写、轻量全栈应用、定时任务，或需要把请求处理与 Cloudflare 的存储、队列和实时状态服务组合起来。
先比较其他平台：你依赖完整 Node.js API、原生二进制、长时间 CPU 任务、守护进程、操作系统权限、复杂文件写入，或者必须把应用进程固定在某个区域。
| 自测问题 | 如果答案是“是” | 初步建议 |
|---|---|---|
| 请求是否需要靠近全球用户处理？ | 是 | 评估 Workers，尤其是 API、鉴权、缓存和重写。 |
| 是否需要关系型数据、文件或异步任务？ | 是 | Workers 分别组合 D1、R2、Queues，不要把所有状态放在全局变量。 |
| 是否需要长驻进程、系统软件或完整文件系统？ | 是 | 优先比较 VPS、容器或具备完整运行时的托管平台。 |
| 是否严重依赖某个 Node.js 原生 npm 包？ | 是 | 先查 Node.js compatibility 和依赖打包结果，再决定是否迁移。 |
| 是否要求明确的数据区域和合规边界？ | 是 | 先确认执行区域、数据存储位置、日志保留和跨区域访问规则。 |
Workers 使用 V8 isolates 和 Web 标准 API，和传统 VPS 或完整容器的运行方式不同。请求处理、数据持久化、文件存储和异步任务应拆分到相应组件，而不是假设 Worker 进程会长期存在。可先阅读 Cloudflare Workers 官方概览 与 Workers 工作原理文档。
Cloudflare Workers 怎么工作：边缘执行不等于无限运行
请求进入 Worker 后，会调用导出的 `fetch()` 处理器。Worker 运行在 Cloudflare 的托管运行时中，多个相互隔离的 isolate 可以承载不同请求。isolate 可能被回收，请求也不保证落到同一个实例，因此全局变量只能作为短暂运行时缓存，不能替代数据库、对象存储或可靠的状态服务。
“边缘执行”主要解决请求处理位置和运维方式问题，并不代表每个请求都会在离用户最近的位置完成全部工作。如果 Worker 仍要访问远端数据库、第三方 API 或固定区域服务，实际延迟还会受到数据源距离、DNS、连接复用、丢包和下游响应时间影响。
| 限制项目 | Workers Free | Workers Paid 标准模型 |
|---|---|---|
| 请求量 | 每天 100,000 次 | 每月包含 10,000,000 次，超出部分按官方价格页计费 |
| CPU 时间 | 每次调用 10 毫秒 | 每次调用默认 30 秒，可配置最高 5 分钟 |
| 内存 | 128 MB | 128 MB |
| 子请求 | 每次请求 50 个 | 每次请求 10,000 个 |
| Worker 大小 | 64 MiB | 64 MiB |
| HTTP 请求墙钟时间 | 官方限制页说明没有固定硬上限，但客户端连接、流式响应、CPU 时间和 `waitUntil()` 仍会影响实际执行。 | |
| Cron、Queue Consumer、Durable Object Alarm 墙钟时间 | 每次调用最高 15 分钟；这是墙钟时间，不等于 CPU 时间。 |
上表依据 Cloudflare 在 2026 年 10 月 31 日可查到的限制页面。CPU 时间只计算代码主动占用 CPU 的时间，墙钟时间还包括等待网络、I/O 和异步操作的时间；两者不能混用。超过 CPU 限制时，官方文档说明可能返回 Error 1102。生产项目应在发布前再次核对 Workers 官方限制页。
请求体大小还取决于 Cloudflare 账户计划，而不只是 Workers 计划。当前限制页列出 Free 和 Pro 为 100 MB、Business 为 200 MB，Enterprise 可配置更高上限；上传大文件时更适合让 Worker 生成授权地址，再由客户端写入 R2，而不是让函数长期转发文件。
从创建项目到上线：一条可执行的部署流程
- 准备 Node.js 与 npm。先安装当前受支持的 Node.js 环境，再确认终端能够运行 `node -v` 和 `npm -v`。
- 创建 Worker 项目。运行
npm create cloudflare@latest -- my-first-worker，按向导选择语言、项目类型和部署方式。 - 进入项目并安装依赖。运行
cd my-first-worker，必要时执行npm install。Wrangler 建议作为项目依赖使用，而不是只依赖全局安装。 - 本地开发。运行
npx wrangler dev，访问终端显示的本地地址，检查响应正文、状态码、请求头和错误日志。 - 首次发布。运行
npx wrangler deploy。未配置自定义域名时，通常先使用 Cloudflare 提供的 Worker 访问地址验证代码。 - 添加配置和密钥。普通配置可以放在 `vars`，密码、API Token 和数据库密钥应使用 Secret，例如
npx wrangler secret put API_KEY。 - 绑定数据服务。在 Wrangler 配置中声明 D1、KV、R2、Durable Objects 或 Queues 绑定，再在代码的 `env` 参数中访问。
- 生产验证。使用
curl -i https://你的域名或浏览器检查状态码、响应头、缓存、跨域、下游 API 和错误日志。
创建、修改、本地运行和首次部署的通用流程可参考 Workers CLI 入门指南。Wrangler 的安装和更新方式以 官方 Wrangler 文档当前内容为准。
环境变量与 Secrets 的区别
普通环境变量适合非敏感配置，例如 API 地址、开关和公开标识。Cloudflare 文档明确建议敏感值使用 Secret，不要把密码或 Token 写进 Wrangler 配置文件。开发环境可以使用 `.dev.vars` 或 `.env`，但不要把这些文件提交到 Git。
可用下面的最小代码读取配置：
export default { async fetch(request, env) { const key = env.API_KEY; return new Response(key ? "configured" : "missing"); } };
Secret、环境变量和部署环境的具体规则见 环境变量文档 与 Secrets 文档。
自定义域名不是部署成功的自动结果
Worker 发布成功，只代表代码已部署，不等于自定义域名已经可访问。Cloudflare 当前文档说明，Custom Domain 需要有效的 Cloudflare Zone 和已部署的 Worker；系统会创建 DNS 记录并处理证书。已有 CNAME、域名不属于当前账户或 Zone 未激活时，接入可能失败。
- 确认域名已经作为有效 Zone 接入当前 Cloudflare 账户。
- 在 Workers & Pages 中选择 Worker，进入 Settings > Domains & Routes。
- 选择 Add > Custom Domain，填写域名或子域名。
- 等待 DNS 和证书状态完成后，用 `curl -I` 检查响应。
- 如果已有其他站点或源站，需要区分 Custom Domain 与 Route，避免把所有路径错误地指向 Worker。
域名配置步骤和限制以 Custom Domains 官方文档为准。
Workers、Pages、D1、KV、R2、Durable Objects 与 Queues 怎么选
| 组件 | 适合处理 | 选型提醒 |
|---|---|---|
| Workers | API、鉴权、Webhook、重写、缓存、Cron 和服务编排 | 不是通用 VPS，也不应依赖进程内状态。 |
| Pages | 静态站点、前端构建产物和 Pages Functions | Pages Functions 按 Workers 方式计费，动态函数仍受 Workers 运行限制。 |
| D1 | SQLite 语义的托管 SQL 数据库，适合用户、订单、配置和关系型业务数据 | 不适合直接保存大文件；需要按一致性、查询量和读写模式评估。 |
| KV | 低延迟键值读取、配置、缓存和读多写少的数据 | 不要把它当作需要强一致事务的主数据库。 |
| R2 | 图片、备份、导出文件、用户上传和其他对象 | 不适合复杂 SQL 查询；大文件上传应减少 Worker 中转。 |
| Durable Objects | 按房间、用户或资源协调实时状态、聊天和协作 | 适合需要单一实体协调的状态，不是所有 CRUD 数据的默认数据库。 |
| Queues | 邮件、转码、同步、批处理和可重试异步任务 | 适合削峰和解耦，不适合同步接口立即返回最终结果。 |
个人项目：先用一个 Worker 完成 API 或网站逻辑，出现结构化数据再加 D1，出现文件再加 R2，出现异步任务再加 Queues。
SaaS：Worker 负责鉴权、租户路由和 API；D1 或外部数据库保存业务数据；R2 保存文件；Queues 处理邮件、报表和同步；需要按房间协调实时状态时再增加 Durable Objects。
高流量网站：先拆分静态资源与动态请求，再观察缓存命中率、动态请求量、平均 CPU 和 P95 CPU。静态资源、缓存和动态 Worker 的计费与性能含义不同，不能只看总访问量。
D1 当前提供托管 SQL、Worker 和 HTTP API 访问，并提供 Time Travel 恢复机制。Time Travel 与数据库迁移是两件事：迁移命令用于变更 schema，恢复能力应通过 D1 的 Time Travel 或导出方案管理，不应声称迁移命令会自动创建独立备份。可参考 D1 官方概览 与 D1 Time Travel 文档。
费用怎么算：按请求、CPU 和配套服务分别估算
截至 2026 年 10 月 31 日，Cloudflare Workers 官方价格页显示 Workers Paid 计划最低为每账户每月 5 美元。该基础计划包含 Workers、Pages Functions、Workers KV、Hyperdrive 和 Durable Objects 的初始用量额度，但不是这些服务的无限使用，也不等于 D1、R2、Queues 和日志全部免费。D1、R2、Queues、日志以及其他服务应分别查看其当前计费规则。
Workers Paid 标准模型当前包含每月 10,000,000 次请求和 30,000,000 CPU 毫秒；超出部分按官方价格页列出的请求和 CPU 单价计费。Cloudflare 当前公开示例显示：每月 15,000,000 次请求、平均每次 7 毫秒 CPU 的 Worker，估算总额为 8.00 美元；每月 100,000,000 次请求、平均每次 7 毫秒 CPU 的示例为 45.40 美元。这些是官方计算示例，不是任何项目的账单承诺。
| 项目假设 | Workers 计算部分 | 不包含或需另算 |
|---|---|---|
| 个人 API：每月 300,000 次请求，每次 CPU 不超过 Free 限制 | 如果每日峰值也不超过 Free 每日请求限制，可先评估 Free 计划 | D1、KV、R2、Queues、日志和其他资源的实际用量 |
| 小型 SaaS：每月 5,000,000 次请求，CPU 总量不超过 Paid 包含额度 | 按当前标准模型，主要是每月 5 美元基础费用 | 数据库读写、文件存储、队列、日志和第三方服务 |
| 中型 API：每月 15,000,000 次请求，平均每次 7 毫秒 CPU | 官方示例为约 8.00 美元 | 配套绑定服务和日志等额外费用 |
| 高流量 Worker：每月 100,000,000 次请求，平均每次 7 毫秒 CPU | 官方示例为约 45.40 美元 | 配套服务、突发流量和其他账户产品 |
成本估算至少要记录：动态请求量、缓存命中率、平均和 P95 CPU、下游 API 次数、D1 读写、KV 读写、R2 存储、Queues 消息量和日志用量。价格页还说明，Workers Logs 将从 2026 年 12 月 1 日开始采用 Cloudflare Observability 定价；上线前应重新查看 Workers 官方价格页，并设置 CPU 上限以降低异常循环或意外流量造成的账单风险。
与 AWS Lambda、Vercel Functions、Deno Deploy 和 VPS 对比
| 平台 | 更适合 | 主要差异 | 选择前核对 |
|---|---|---|---|
| Cloudflare Workers | 边缘 API、缓存、Webhook、鉴权、轻量全栈和 Cloudflare 资源组合 | V8 isolates、绑定式资源、全球网络执行 | CPU、内存、包大小、数据位置和 Node.js API 兼容性 |
| AWS Lambda | AWS 事件生态、事件驱动后端和需要多种托管集成的任务 | 函数与 AWS 事件源、权限、区域和其他服务结合 | 区域、VPC、并发、权限复杂度和最长执行时间 |
| Vercel Functions | Next.js、SSR、前端框架 API、流式响应和区域化函数 | 与前端部署、CDN、框架构建和函数运行时结合 | 函数区域、Node.js 运行时、函数时长、内存与数据源距离 |
| Deno Deploy | Deno、TypeScript、JavaScript 及 Deno 原生 API 生态 | 托管环境使用标准 Deno 运行时，支持 JSR、NPM 依赖和 Deno 工作流 | 当前 Deploy Runtime 对文件、子进程、FFI、原生扩展和权限的具体支持 |
| 传统 VPS | 长驻进程、守护服务、完整文件系统、自定义网络和容器化应用 | 拥有操作系统级控制权 | 补丁、监控、扩容、备份、安全和故障恢复都需自行负责 |
Workers 的 Node.js 兼容并不等于完整 Node.js。Cloudflare 文档说明，Workers 提供部分 Node.js API；兼容日期为 2026 年 8 月 4 日或更晚的新项目默认启用相关兼容能力，但某些 API 仍可能是部分实现或仅提供可导入但不可实际调用的 stub。使用 npm 包前，应检查它是否依赖未实现的模块、原生扩展、动态加载或长期进程。参考 Node.js compatibility 文档。
Vercel 官方文档将其函数描述为按区域运行的托管函数，并支持 Node.js、Python、Rust、Go、Ruby、Bun 和 Edge 等运行时；Deno Deploy 文档则说明其托管环境使用标准 Deno 运行时。两者都不应简单概括为“更快”或“更便宜”，应结合代码依赖、数据库区域和实际账单模型判断。对比资料可查看 Vercel Functions 运行时文档、Deno Deploy Runtime 文档 与 AWS Serverless 官方指南。
生产上线、日志、回滚与连接故障分流
- 部署成功但接口报错：先运行
npx wrangler tail，区分代码异常、Secret 缺失、绑定名称错误和下游 API 超时。 - 本地正常、线上失败：检查生产环境是否配置了同名 Secret、D1 数据库、KV namespace、R2 bucket、Queue 和环境变量。本地文件不等于线上资源。
- 数据库迁移后异常：先检查远程迁移状态和 schema，再确认是否需要使用 D1 Time Travel 恢复。不要把迁移命令当成自动备份命令。
- 请求超时或 CPU 超限：分别记录 CPU 时间、墙钟时间、子请求数量、响应体大小和下游等待时间；把邮件、转码、同步和批处理拆到 Queues 或 Workflows。
- 依赖无法打包：检查 npm 包是否依赖原生二进制、动态加载、未实现的 Node.js API 或长期进程；必要时改用 Web API 兼容库，或迁移到完整运行时。
- 新版本上线异常：保留版本号和变更记录，先使用
wrangler rollback回到稳定版本，再定位代码、绑定和数据结构差异。 - 域名打不开：先分别测试 Worker 默认地址和自定义域名。如果默认地址正常而自定义域名失败，重点检查 Zone、DNS、证书、Custom Domain、Route 冲突和缓存。
- 访问变慢或丢包：记录客户端网络、DNS 解析结果、TLS 建连、首字节时间、下游 API 响应和不同网络环境结果，不要把 Worker 代码问题与链路问题混为一谈。
Cloudflare 的回滚会创建新的部署并将选定版本重新设为活动版本，但不会自动恢复已经改变的 KV、D1、R2、Queue 或 Durable Object 资源；数据结构发生变化时，回滚代码仍可能与当前数据不兼容。具体限制见 Workers Rollbacks 文档。
上线前建议采用“一个 Worker、一个最小绑定、可查看日志、可回滚版本”的最小闭环。确认请求、密钥、域名、数据迁移和监控都能验证后，再增加缓存、队列、实时状态和多环境发布。
常见问题
Cloudflare Workers 是不是 VPS？
不是。Workers 是托管边缘函数运行时，开发者提交代码并通过请求、定时器或队列触发执行；VPS 提供操作系统、进程、文件系统和网络配置控制权。需要长驻进程、系统软件或守护服务时，应比较 VPS 或容器。
Cloudflare Workers 免费吗？
有 Free 计划，但不是无限使用。当前官方限制页列出 Free 每天 100,000 次请求、每次调用 10 毫秒 CPU 时间和 128 MB 内存。Paid 计划最低为每账户每月 5 美元，并按请求、CPU 和配套服务用量计算；D1、R2、Queues 和日志不能直接理解为全部包含在基础费用内。
Workers Paid 每月 5 美元是不是包含所有 Cloudflare 服务？
不是。当前价格页说明 Paid 计划包含 Workers、Pages Functions、Workers KV、Hyperdrive 和 Durable Objects 的初始用量额度；D1、R2、Queues、日志等服务应按各自当前价格和用量单独核对。
Workers 能运行 Node.js 和 npm 包吗？
可以使用部分 Node.js 兼容 API 和许多 npm 包，但不是完整 Node.js 服务器。兼容日期为 2026 年 8 月 4 日或更晚的新项目默认启用相关兼容能力，但部分模块仍可能不完整，依赖原生扩展、长期进程、动态加载或未实现 API 的包需要单独测试。
Workers 能保存数据吗？
可以，但不要依赖全局变量保存持久数据。D1 适合关系型 SQL 数据，KV 适合低延迟键值读取，R2 适合文件和对象，Durable Objects 适合按实体协调实时状态，Queues 适合异步任务。应根据一致性、查询方式、数据大小和任务时长选择组件。
Workers 和 Pages 有什么区别？
Workers 更偏向通用请求处理、API 和边缘后端；Pages 更适合静态站点、前端构建产物以及 Pages Functions。Pages Functions 按 Workers 方式计费，因此动态函数仍要遵守相应的运行时、请求和 CPU 规则。
自定义域名为什么部署成功后仍然打不开？
部署成功只代表代码已发布，不代表域名配置完成。检查 Zone 是否在当前账户、Custom Domain 是否添加成功、DNS 和证书状态是否正常，以及是否存在已有 CNAME、Route 冲突或缓存。可以先访问 Worker 默认地址，判断问题位于代码还是域名链路。
D1 迁移会自动创建备份吗？
不要这样理解。D1 schema 迁移负责应用数据库变更；当前生产存储系统使用 Time Travel 提供按时间点恢复能力，具体保留时间和适用限制以官方文档为准。迁移前仍应确认远程状态、测试迁移顺序，并准备恢复或导出方案。
Workers 适合长时间任务吗？
要区分任务类型。HTTP 请求的墙钟时间、CPU 时间和后台 `waitUntil()` 行为不同；Cron、Queue Consumer 和 Durable Object Alarm 当前每次调用的墙钟时间上限为 15 分钟，而 CPU 时间仍受计划和配置限制。更长或持续占用进程的任务应比较 Workflows、容器、VPS 或其他完整运行时。