为什么越来越多的开发者开始放弃传统服务器？
你有没有遇到过这种情况：用户在地球另一端访问你的 API，延迟高达 300ms 以上，页面卡顿明显，但你又没有预算在每个大洲都部署一台服务器？这正是边缘函数（Edge Functions）要解决的核心问题。
传统的 API 部署模式是把代码放在一台固定的服务器上——无论是自购的物理机、VPS（虚拟专用服务器），还是云服务商的实例。所有请求都要回源到这台机器，地理距离越远，延迟越高。而 Cloudflare Workers 提供了一种全新的思路：把你的 API 代码分发到全球 300 多个边缘节点，用户请求在离他最近的节点执行，从根本上消除了回源延迟。
这篇文章会带你从零开始，用 Cloudflare Workers 部署一个真实的 API 服务。我们不讲概念，只讲怎么做——从环境搭建、代码编写、数据源对接，到最终上线的完整流程。
十分钟搞定：从环境搭建到第一个 API 上线
在动手之前，先说一下 Workers 的运行原理。它基于 V8 引擎（和 Chrome 浏览器相同的 JavaScript 引擎），每个请求在一个轻量级的隔离沙箱中执行，冷启动时间通常在 5ms 以内。相比传统云函数动辄 200-500ms 的冷启动，这个差距在高并发场景下会非常明显。
第一步：初始化项目
确保本地安装了 Node.js 16 以上版本，然后用 Wrangler CLI 创建项目：
npm create cloudflare@latest my-api-worker cd my-api-worker
创建过程中选择 “Hello World” 模板，框架选 “None”。完成后你会得到一个标准的 Workers 项目结构。
第二步：编写 API 逻辑
打开 src/index.js，写一个简单的 REST 风格 API：
export default {
async fetch(request, env) {
const url = new URL(request.url);
if (url.pathname === '/api/health') {
return Response.json({
status: 'ok',
region: request.cf?.colo,
timestamp: Date.now()
});
}
if (url.pathname === '/api/greet' && request.method === 'POST') {
const body = await request.json();
return Response.json({
message: `Hello, ${body.name}!`,
edge_node: request.cf?.colo
});
}
return new Response('Not Found', { status: 404 });
}
};
这里有几个关键点：request.cf 对象包含了请求到达的边缘节点信息，colo 字段代表用户连接的最近数据中心代号。通过这个字段，你可以验证请求确实是在边缘执行的。
第三步：本地测试与部署
# 本地开发测试 npx wrangler dev # 部署到 Cloudflare 全球网络 npx wrangler deploy
部署成功后，Wrangler 会返回一个 *.workers.dev 域名。用 curl 测试一下：
curl https://my-api-worker.<你的子域>.workers.dev/api/health
返回的 region 字段会显示你当前连接的边缘节点。如果你在国内访问，通常会命中香港或东京节点。整个部署过程不需要配置任何服务器、DNS（域名系统）记录或反向代理——Cloudflare 全部帮你处理了。
不只是 Hello World：对接真实数据源
一个没有数据存储的 API 没什么实际价值。Workers 生态提供了三种主流的数据存储方案，适合不同的业务场景。
KV 存储：适合配置和缓存
Workers KV 是一个全球分布式的键值存储，读取延迟通常在 10ms 以内。它特别适合存储配置信息、会话 token、用户偏好等读多写少的数据：
// wrangler.toml 中绑定 KV 命名空间
// [[kv_namespaces]]
// binding = "CONFIG_STORE"
// id = "your-kv-namespace-id"
export default {
async fetch(request, env) {
const cached = await env.CONFIG_STORE.get('site_config', { type: 'json' });
if (cached) {
return Response.json(cached);
}
const config = { theme: 'dark', version: '2.1' };
await env.CONFIG_STORE.put('site_config', JSON.stringify(config));
return Response.json(config);
}
};
KV 的写入是最终一致性的，全球同步可能需要几十秒。如果你的场景需要强一致性的读写，比如库存扣减或订单状态，KV 就不太合适了。
D1 数据库：关系型数据的最佳选择
D1 是 Cloudflare 提供的 SQLite 兼容边缘数据库。对于需要 SQL 查询能力的场景——比如用户管理、内容管理、订单系统——D1 是目前 Workers 生态中最实用的选择：
export default {
async fetch(request, env) {
const { results } = await env.DB.prepare(
"SELECT * FROM articles WHERE status = ? ORDER BY created_at DESC LIMIT 10"
).bind('published').all();
return Response.json(results);
}
};
D1 的数据库文件会自动复制到全球边缘节点，读请求走边缘、写请求走主节点，兼顾了低延迟和数据一致性。目前免费版支持每天 500 万次读取和 10 万次写入，对于中小型项目来说完全够用。
R2 存储：大文件和静态资源
如果你的 API 需要处理图片、视频或大型 JSON 数据集，R2 对象存储可以与 Workers 无缝配合。和传统 CDN（内容分发网络）不同，R2 存储和计算在同一个边缘网络内，数据传输零出口费用——这一点在处理大量静态资源时能显著降低成本。
对比一下：Workers 和传统部署方案到底差在哪？
选技术方案不能只看宣传，得看实际差异。下面从几个关键维度对比 Workers 和传统 VPS / 云服务器（基于云计算的虚拟主机）部署：
冷启动延迟方面，Workers 的 V8 Isolate 模型冷启动通常在 5ms 以内，而传统云函数（如 AWS Lambda）冷启动在 100-500ms，VPS 上的 Node.js 服务虽然没有冷启动问题，但需要持续运行，资源占用是固定的。
运维成本上，Workers 免费版每天 10 万次请求，付费版每百万次 $0.30（截至 2026 年 6 月，以 Cloudflare 官网实时价格为准），不需要操心操作系统更新、安全补丁、SSL（安全传输协议）证书续期。相比之下，一台入门级 VPS 每月至少 $5-10（价格仅供参考，不同服务商差异较大），还需要自己处理运维。
扩展性是 Workers 最大的优势之一。当流量突然暴增时，Cloudflare 会自动在所有边缘节点调度资源，你不需要做任何配置。而传统架构需要提前规划带宽（数据传输速率）和服务器规格，流量峰值超出预期时很容易宕机。
但 Workers 也有明显的局限。执行时间限制在免费版 10ms、付费版 30 秒，不适合长时运行的任务；运行环境只支持 JavaScript / TypeScript / WebAssembly，不能跑 Python、Go 等语言的服务；没有持久化的文件系统，数据必须存在 KV、D1 或 R2 中。如果你的业务需要长时间运行的后台任务，或者依赖特定的系统库，传统的独立服务器方案可能更合适。
总结：什么场景下该选 Workers，什么场景该选传统方案？
经过上面的分析，我们可以给出一个清晰的决策框架。
适合用 Workers 的场景：API 网关和路由层、A/B 测试和灰度发布、认证鉴权中间件、轻量级 REST API、静态页面的动态增强、Webhook 接收和转发。这些场景的共同特点是请求处理时间短、逻辑相对独立、对全球分发有需求。
不适合 Workers 的场景：需要长时间运行的后台任务（如视频转码）、依赖特定操作系统能力的服务（如图像处理库）、需要持久化文件系统的应用、对冷启动延迟极度敏感的实时通信服务。
如果你的项目属于第一类场景，建议从一个内部 API 或 Webhook 接收器开始试水。Workers 的免费额度足够你验证可行性，确认效果后再逐步迁移更多逻辑。而对于需要完整服务器环境的业务，Hostease 提供从 VPS 到独立服务器的多种方案，可以和 Workers 互补——用 Workers 处理边缘逻辑，用传统服务器承载核心业务，各取所长。