Cloudflare Workers 是什么
一句话总结
Cloudflare Workers 是运行在 CF 全球 330+ 边缘节点的无服务器执行环境，基于 V8 Isolate 技术，让你在距离用户最近的地方跑 JavaScript/TypeScript 代码。
🤔 为什么会有它 / 解决了什么问题
传统 Serverless（AWS Lambda）有冷启动延迟，且运行位置离用户远。Workers 把计算推到网络边缘，响应时间从几百毫秒降到几十毫秒。
🔍 具体原理 / 运作逻辑
每个请求分配给一个轻量级 V8 Isolate（不是完整容器），资源隔离由 V8 沙箱保证。代码部署到所有边缘节点，请求基于 Anycast 路由到最近的节点执行。
更硬核的技术细节（点击展开）
V8 Isolate 启动耗时约 5ms，远快于容器冷启动（数百毫秒）。每个 Isolate 独享 128MB 内存，CPU 执行时间限制 30s（免费计划 10ms/天）。Service Worker 或 ES Module 格式均可。
🧭 什么情况下会用到 / 什么场景会遇到它
- 构建 API 网关 / 反向代理（Kong 的轻量替代，如 Growth App 的
*.getgrowth.app路由） - A/B 测试、URL 重写、请求/响应变换
- 实时数据聚合（在边缘端合并多个上游 API 结果）
🛠️ 怎么上手 / 在哪操作
登录 Cloudflare Dashboard → Workers & Pages → 新建 Worker，或通过 wrangler CLI 本地开发和部署。
⚖️ 副作用 / 代价 / 取舍
- 每个请求 CPU 时间上限 30s（含子请求等待时间），不适合长时间任务如视频转码
- 不支持所有 Node.js 内置 API（
fs、net等），必须用 CF 运行时 API - 单 Worker 内存上限 128MB
🕰️ 来历
- 谁提出/创造的：Cloudflare（Kenton Varda 团队，他也是 Cap’n Proto 作者）
- 什么时候出现的：2017 年 9 月公开测试，2018 年 3 月正式 GA
🔗 关联 / 经常一起出现的概念
- Service Bindings：不经过网络直接调用另一个 Worker，延迟更低
- Cloudflare D1：Workers 通过 Hyperdrive 连接 D1，在边缘读写 SQLite
- Durable Objects：为 Workers 提供有状态的全局协调能力
⚠️ 注意事项 / 常见误区
Free 计划每天 10 万请求，但 Workers Unbound（长任务）限额需单独查看，按 CPU 时间计费而非请求次数。
📎 记忆锚点
“每次请求一个新沙箱，5ms 启动，边缘执行完就销毁。”
📝 更新日志
| 日期 | 改动 | 原因 |
|---|---|---|
| 2026-07-13 | 首次创建 | - |