02 — Cloudflare 如何解决（机制与产品映射）¶
本章把上一篇的痛点映射到 Cloudflare 的机制：全球 Anycast 网络、Workers 运行时（基于 V8 isolate 的 workerd）、绑定（Bindings）、以及 Pages / Workers 上的全栈组合。下列能力与表述以官方文档为据。
1. 延迟与路径：把逻辑放到边缘¶
- 请求在就近入网点进入，Worker 的
fetch处理器在边缘执行，可直接返回Response或再fetch回源。 - 对「既要算、又要近」的场景，这比「仅缓存静态文件、动态全回源」更灵活。
参考：Workers 概念 — Compute per request
2. 扩展与冷启动：isolate 模型¶
Workers 使用 isolate：在已有运行时进程内创建轻量沙箱，而非为每次调用启动完整容器进程。官方文档强调：
- 单实例可调度大量 isolate，切换成本低；
- isolate 内存彼此隔离，适合多租户与不可信代码场景（另有 Workers for Platforms 的隔离模式说明）；
- 不要在 Worker 全局作用域依赖可变状态——同一 isolate 可能并发处理多个请求，且请求未必路由到同一实例。
3. 静态 + 动态：全栈的一条龙路径¶
- Cloudflare Pages：连接 Git 或上传静态资源，Pages Functions 在边缘运行动态逻辑（认证、表单、API 等），与 Workers 同属 Workers 运行时能力子集。
- 带静态资源的 Workers：静态请求与 Worker 脚本组合部署（官方文档中说明 Pages 与 Workers 在功能与成本结构上可对比、迁移）。
参考：
4. 数据与集成：Bindings 把资源「类型化」接入¶
Bindings 让 Worker / Pages Functions 通过 env 访问 KV、D1、R2、Durable Objects 等资源，而无需在代码里散落原始 endpoint 字符串；配合 wrangler types 可把配置映射成 TypeScript 的 Env。
4.1 数据库、AI 与向量（另文展开）¶
Bindings 与存储选项还涵盖 D1（serverless SQL）、Vectorize（向量库）、Workers AI（推理 binding）、经 AI Gateway 的统一调用，以及通过 Hyperdrive 访问传统 Postgres/MySQL 等路径。官方在 Storage options 中把这些与 Queues、R2 一并归类。
专题详解见：06 — 数据层、AI、向量与 RAG。
5. 安全与网络能力（概览）¶
- DDoS 防护、WAF、Bot 管理等位于 Cloudflare 网络栈中，可与站点同平面启用（具体产品与套餐见各自文档章节）。
- 本章不展开零信任产品线，仅强调：边缘平台可把「安全策略」从应用里部分抽离。
6. 限制即「设计约束」：CPU、内存、子请求¶
官方文档明确：
- CPU 时间：衡量的是执行代码的时间；等待
fetch/存储 I/O 一般不计入 CPU 时间（与 wall time 不同）。 - 内存：每 isolate 128 MB（含 JS 堆与 Wasm 等），超标时运行时会换 isolate 或在高负载下取消部分请求。
- 套餐/默认配额差异：免费与付费在每日请求、默认 CPU 上限、子请求次数等方面不同，需以 Workers limits 为准。
这些限制反过来迫使架构师把重 CPU、长事务、大批量批处理迁到异步队列、批处理服务或 Durable Objects 等更合适的位置。