03 — 方案优劣与选型理由

本章用「是否选 Cloudflare + TypeScript」的决策视角，归纳优势、劣势与典型适用/不适用场景。数值与套餐以 Workers limits 与定价页为准，会随时间调整。

优势（Why Cloudflare）

1. 全球边缘就近执行
   动态逻辑可在入网点运行，减少回源与地理延迟，适合个性化路由、边缘鉴权、轻量聚合 API。

2. 隔离模型带来的扩展与多租户潜力
   isolate 启动与切换成本低，官方文档对比了与传统「每函数一容器进程」模型的差异；对平台类产品可结合 Workers for Platforms 等方案。

3. 统一的全栈交付面
   静态资源 + Worker/Pages Functions + 存储绑定（R2、D1、KV、DO）可在同一平台内闭环，减少「CDN 一组、API 一组、对象存储再一组」的割裂。

4. 出站流量成本结构（R2 等）
   R2 等产品强调避免典型云存储的 Egress 费用模式（详见 R2 文档Pricing章节），对大量公网分发的数据面更友好。

5. TypeScript 一等公民与类型生成
   官方写明：Workers API fully typed，类型来自开源运行时 workerd；推荐用 wrangler types 生成与配置一致的 Env 与 RPC 相关类型。

参考：TypeScript - Workers

1. 可预测的计费维度
   Workers 付费计划对请求数、CPU 时间等维度计费；可通过 Wrangler limits.cpu_ms 等设置上限，缓解「误循环 / 被刷接口」带来的账单风险（见定价与 configuration 文档）。

劣势与边界（Trade-offs）

1. 不是 Node.js 运行时
   Workers 提供 Web 标准 API 与 Node 兼容子集（nodejs_compat 等），而非完整 Node。依赖大量原生 addon、特定文件系统语义、长连接模型的库可能需替换或改造。

2. CPU 与内存硬顶
   每请求 CPU 时间、每 isolate 128 MB 内存是硬性设计约束。重计算、大 JSON 解析、巨型缓冲必须在架构上拆分或外移。

3. 并发与全局状态心智负担
   同一 isolate 可能并发处理多请求，且请求不一定落到同一 isolate——有状态逻辑要显式用 Durable Objects、D1、KV 等，而不是进程内变量。

4. Pages Functions 绑定子集
   Pages Functions 仅支持 Workers 绑定的一个子集，复杂绑定或高级能力可能需要纯 Workers 项目或迁移路径。

5. 厂商锁定与学习曲线
   深度使用 Bindings、Cache API、Request CF 元数据等会形成平台惯性；团队需投入学习 Wrangler、compatibility_date、Observability 工具链。

为什么选「Cloudflare + TypeScript」这套组合（典型理由）

• 团队已是 TS 全栈：前后端共享类型、RPC stub、生成 Env，能降低集成错误率（见 RPC TypeScript）。
• 产品形态以站点/API 为主、流量全球分布：边缘计算收益大；若用户与数据都在单一区域且极重事务，需评估是否仍以传统区域化服务为主。
• 希望减少运维表面积：少维护虚拟机集群与多产品拼接，把边缘规则、计算与静态资源尽量收敛。
• 数据面大量出站读：对象存储与分发场景可重点算 R2/CDN 与其他云的 TCO。

何时可能不选或少用

• 强依赖完整 Node 生态、重 CPU/长任务为主的核心链路。
• 强一致事务 + 复杂查询占主导，且不愿接受拆分读写、异步化。
• 监管/合规要求计算与数据必须落在特定主权区域且边缘模型难以满足（需法务与架构共同评估）。

与其他技术栈怎么比？

与 Java EE/Jakarta EE、Python（Django/FastAPI）、经典 Node、区域云函数 等在部署单元、运行时与 AI 生态上的对照，见：07 — 横向对比。

---

下一篇：TypeScript 工程化与落地。