Cloudflare 橙皮书

判断先放在前面：Cloudflare 不是“一个 CDN”，而是一层把流量入口、执行逻辑和基础数据能力收在一起的工作台。它最值钱的地方，不是某个单点功能，而是你把站点接进来以后，后面的很多动作都还能留在同一条链路里。

它先解决什么

Cloudflare 先解决的不是“我给你算力”，而是“你的请求怎么安全、稳定、可控地进来”。这件事一旦站稳，后面的很多能力才有地方挂上去。

真正稀缺的是上下文没有断

Cloudflare 的价值，不在于“产品很多”，而在于入口、计算、安全和数据之间的上下文没有断。你改一个域名接入时，看到的是同一套网络；你写一个 Worker 时，接到的也是同一套绑定和存储。

这和把 DNS、CDN、WAF、函数、存储、数据库分散在好几家服务里的做法不一样。Cloudflare 也有复杂度，但它把复杂度压在同一个控制面里，排查和扩展时会省很多翻译成本。

适合谁

如果你的项目是内容站、文档站、产品官网、API 门面、活动页、个人项目，或者一个还不算很重的小 SaaS，这一层通常都值得先放进来。

它特别适合两类事情：一类是离用户很近的流量入口，另一类是能在边缘顺手处理掉的小逻辑。只要你的问题还在“怎么更稳地接住请求、怎么更快地把内容送出去、怎么少写一点中间层胶水”，Cloudflare 就很顺手。

常见误解

别把 Cloudflare 想成“把所有后端都搬进来”的平台。它的强项仍然在入口、分发、安全和靠近流量的执行层，不是在取代一切重型后端。

也别把它想成“只要挂上去就会自动变快”。它能帮你把路径变短，把边缘资源用起来，但缓存策略、响应头、回源行为和应用结构这些东西，还是要自己想清楚。

边界在哪里

如果你的核心问题是重事务数据库、特别复杂的内网拓扑、超长后台任务，或者必须严格落在某个本地合规环境里，Cloudflare 就不一定是最顺手的主场。

所以这章最重要的判断很简单：Cloudflare 不是一朵“万能云”，它是把 Web 入口相关的麻烦收拢起来的那一层。对很多开发者来说，真正值钱的不是它有多神，而是它让你少在不同系统之间来回切换。

核心建议：先把 Cloudflare 当成入口层和边缘控制面来理解，再去看它的计算和数据产品。这样后面的产品关系会顺很多。

判断先放前面：开发者会留在 Cloudflare，通常不是因为它在某一个点上碾压所有对手，而是因为从想法到上线、再到补能力的路径很短。

它让原型不容易死在上线前

很多平台的问题，不是不能做，而是做着做着就把人劝退了。Cloudflare 的好处，是它对“先跑起来”这件事很友好。Pages 能直接接 Git，Workers 也很适合快速发一个可用版本。

这对小团队和个人项目特别重要。你最缺的往往不是组件数量，而是连续性。你不想刚写完页面，就被证书、缓存、函数入口、权限、回源地址、对象存储这些东西打断好几次。

它把上线和稳住放在一起

很多轻量平台只解决“发上去”。Cloudflare 更讨巧的地方在于，它把上线之后那点常见麻烦也顺手包住了：SSL、缓存、WAF、限流、基础 Bot 识别，这些东西不会总是一键到位，但它们至少不是完全分散的。

对很多开发者来说，这就是留下来的原因。不是因为某个功能惊艳到不可替代，而是因为你一旦开始在这里搭东西，后面要补的能力也大多还在同一个地方。

它省下来的其实是注意力

“不用管服务器”这种说法太老了，也不够准确。更真实的好处是，你少花了很多注意力在基础设施翻译上。

你不用先想清楚哪台机器在哪个区，入口层、缓存层、函数层、存储层怎么拼，海外和国内流量要不要分两套看。很多时候，你先把业务逻辑写对，再把边界往外补。

这对内容产品、轻 SaaS、内部工具、文档站和一些 AI 小应用尤其明显。它们大多不需要一开始就建一套很重的平台工程。

适合谁

它特别适合那些“先做出一个完整闭环，再考虑复杂架构”的项目，而不是一开始就要把基础设施设计成论文的项目。

常见误解

别把 Cloudflare 留人的原因理解成“它最便宜”或者“它天然最快”。价格和速度当然会影响选择，但更本质的原因是，它把很多开发动作串成了连续动作。

你会发现自己不是在“用几个独立服务”，而是在“在同一个地方慢慢把系统长出来”。这就是它黏人的地方。

边界在哪里

如果你的项目已经明显进入重数据库、重事务、超长任务、复杂内网或者强本地化合规这几类区域，就别把 Cloudflare 想成万能解法了。

这类场景里，Cloudflare 也许还能放在前面做入口，但它不一定适合作为全部主干。真正好的架构，不是一直往 Cloudflare 上加，而是知道什么时候该停一下，换别的底座更省力。

所以这章的结论很简单：开发者会一直留在 Cloudflare，不是因为它无所不能，而是因为它把“做出来”和“别太脆”放在了同一条路上。

核心建议：把 Cloudflare 当成“连续性工具”看，会比把它当成“功能列表”看更接近真实使用方式。

判断先放前面：Cloudflare 的正确学法不是背产品名，而是先分清入口、计算、数据、异步和 AI 这几层各管什么。

先抓住五条主线

Cloudflare 的开发者平台可以先压成五条线来看。

• 入口与发布：Pages、DNS、Cache
• 计算：Workers、Pages Functions
• 数据：R2、D1、Durable Objects、KV
• 异步：Queues、Workflows
• AI：Workers AI、Vectorize、Agents SDK

这样看，很多产品突然就不散了。你不用先学完整个平台，只要先知道每一类在解决什么问题。

这张图怎么用

别拿它当考试提纲。它的作用是帮你在真正要做事的时候少走弯路。

先学 Pages 和 Workers

如果你是从前端、内容站或者小应用切进来，Pages 往往是更轻的起点。它适合先把站点发出去，再慢慢加动态逻辑。

Workers 则更像平台中枢。它的价值不在于“跑一段 JS”这么简单，而在于它站在流量入口旁边，能直接接请求、接绑定、接存储、接外部 API。很多边缘逻辑、API 门面和轻量业务处理，最终都会绕到它这里。

数据层别混着理解

R2、D1、Durable Objects 这三个名字经常被新手混成“都是存东西”。其实它们处理的是完全不同的问题。

• R2 更像对象存储，适合文件、图片、音视频和导出包。
• D1 更像轻量关系数据库，适合结构化数据和没那么重的业务表。
• Durable Objects 更像状态协调点，重点不是“存多少”，而是“把同一份在线状态和并发收在一起处理”。

很多人第一次上 Cloudflare 会把 D1 当万能主库，把 Durable Objects 当数据库来用。这个理解通常会在后面吃亏。它们不是谁替谁，而是各管一段。

AI 栈已经连起来了

Cloudflare 这几年最明显的变化，是它开始把 AI 相关能力串成一条路。

Workers AI 负责推理，Vectorize 负责向量检索，Agents SDK 则把有状态 agent 的思路放到 Durable Objects 上。这个组合的价值不在于每个单品都赢过所有竞品，而在于它们能放在同一个边缘平台里协作。

如果你要做 AI 应用，这条路线很值得先看。因为你通常不只是在找“模型”，你还在找入口、记忆、检索和状态怎么连起来。

常见误解

别把 Cloudflare 学成产品目录。目录看完了，不代表你会用。真正有用的，是知道先后顺序。

如果你只需要一个静态站，就先学 Pages；如果你要一层请求处理，就补 Workers；如果你要文件，再看 R2；如果你要轻结构化数据，再看 D1；如果你开始处理协同、会话、在线状态，再看 Durable Objects。

边界在哪里

也别每个产品都平均用力。Cloudflare 的产品很多，但读者真正需要的不是“全都知道”，而是“知道哪一个先碰，哪一个后碰，哪一个暂时别碰”。

所以这章最重要的建议其实很朴素：先按问题学，不按名词学。先知道自己缺入口、计算、数据、异步还是状态，再去看对应产品，会省很多时间。

核心建议：产品地图的作用不是让你背下来，而是让你在真实项目里先选对第一站。

判断先放前面：DNS、Anycast、CDN 和 Cache 不是一个东西，只是 Cloudflare 把它们放进了同一条入口链路里。

先把四件事分开

最简单的理解方式，是把它们拆成四层。

• DNS 负责“名字指向谁”
• Anycast 负责“流量从哪里进来”
• CDN 负责“内容怎么分发得更近”
• Cache 负责“哪些响应可以先留在边缘”

这四层都和“快”有关，但快的方式不一样。DNS 只是解析，不等于传输。Anycast 让入口更靠近用户，但不等于内容已经在本地。CDN 是分发系统。Cache 则是具体存哪一份响应、存多久、什么时候回源。

Cloudflare 不是只做其中一层

Cloudflare 的巧妙之处，在于它把这些层放在了一起。你改域名接入时，DNS、TLS、缓存、安全规则和边缘逻辑就已经开始串联了。

这比单独看每个名词更重要。很多团队的问题不是“不知道 CDN 是什么”，而是每一层都分散在不同地方，出了问题之后不知道该先看谁。Cloudflare 把入口收拢后，很多问题更容易定位。

适合谁

它真正帮你省的是思考成本

你不需要每次都想“这是不是 DNS 的问题”“这是不是回源的问题”“这是不是缓存没命中”。如果你在 Cloudflare 里做过几次配置，慢慢就会知道：有些问题是解析，有些问题是入口，有些问题是缓存策略，有些问题其实是源站本身。

这也是为什么很多人把 Cloudflare 当成“网站先稳住”的第一站。它不是神奇地让所有东西变快，而是让你更容易把该快的部分放到离用户近的地方。

常见误解

别把“开了 Cloudflare”直接等于“网站自动加速成功”。如果回源很慢、页面太动态、缓存头没配好，或者你的内容本来就不能缓存，那你再怎么调入口也不会凭空变快。

也别把 Anycast 当成 CDN。Anycast 解决的是入口怎么落点，CDN 解决的是内容怎么分发；这两件事有关联，但不是一回事。

边界在哪里

如果你的响应高度个性化，或者每次请求都强依赖实时状态，那就别为了追求快而硬上缓存。缓存能救很多站点，也能把很多 bug 变得更隐蔽。

同样，如果你现在真正的问题是应用逻辑慢、数据库慢、接口设计太重，那先别急着怪网络。网络层能改善的是分发和入口，不会替你把业务本身重写一遍。

所以这章最值得记住的判断是：Cloudflare 不是把 DNS、Anycast、CDN、Cache 混成一个词，而是把它们放进同一个工作台里。你越懂每层在干什么，就越知道该在哪一层下手。

核心建议：网络层先分层理解，再谈优化。顺序错了，后面的加速很多时候只是表面工作。

判断先放前面：WAF、Rate Limiting、Bot Management 不是一层外挂，也不是一个按钮，它们是三种不同的入口防线。

Cloudflare 的好处，是这些策略都放在离流量入口很近的地方。你不必把每个请求先送进源站，再慢慢判断它是不是可疑。很多常见风险，在入口层就可以先分流。

三个能力，管三件事

• WAF 主要看请求长什么样，适合挡一批已知的 Web 攻击和异常模式。
• Rate Limiting 主要看同一类请求来得是不是太密，适合压住突发滥用和刷接口。
• Bot Management 主要看流量像不像自动化程序，适合识别和处理爬虫、脚本和非人类行为。

这三者不是互相替代，而是互相补位。把它们混成一类，最后往往会出现“明明加了安全，为什么还是有问题”的错觉。

适合谁

如果你有公开网站、登录页、注册页、搜索接口、评论接口、下载接口或者公开 API，这三类能力基本都值得认真看。

尤其是这种场景：你知道会有正常用户，也知道会有人试探、扫站、刷接口、抓内容。Cloudflare 的入口安全能力就在这里很值钱，因为它不是让你等到应用层报错后再补救，而是先在门口做一点判断。

规则型限流和代码型限流

常见误解

别把 WAF 当成应用鉴权。WAF 再强，也不是“谁能登录、谁能看数据、谁能改配置”的权限系统。

别把 Rate Limiting 当成完整反爬。限流能压住短时间的爆发，但不能替你判断业务身份、账号行为和风控规则。

也别把 Bot Management 当成“所有自动化都要杀掉”。很多正经业务本身就有自动化客户端、爬取、预取、监控或者集成流量，关键不是全拦，而是分清楚什么该放，什么该挡。

边界在哪里

如果你的问题是内部员工访问、租户隔离、设备信任、应用权限这些更偏“谁能进系统”的事，那你要看的就不只是 WAF 了，而是后面的 Zero Trust、Access、Tunnel 那条线。

如果你的问题已经变成高级对抗、长期滥用、复杂脚本行为，也别指望入口层能一劳永逸。安全从来不是一层解决全部，而是入口、应用、日志和人工判断一起配合。

另外，Rate Limiting 这类规则不是精确记账系统。官方已经说明，计数更新会有延迟，所以它更适合做门口控制，不适合拿来当精确配额账本。

所以这章的核心判断是：Cloudflare 的安全不是外挂式加法，而是入口层的一组不同切面。你越早把 WAF、限流和 Bot 识别分开，后面越不容易把安全理解成一个模糊的“大开关”。

核心建议：先按“看什么信号”来选安全能力，再按“要拦、要限、还是要识别”来落规则。

判断先放前面：私有应用接入 Cloudflare，顺序不是先研究一堆安全名词，而是先收住入口，再管谁能进来。

先把顺序摆正

别把 Tunnel 想成普通反向代理，它更像是一条由你的机器主动连出去的受控通道。官方的主线就是 outbound-only，不需要你把源站对公网直接开口。

Tunnel 的价值不是“酷”，而是省掉暴露 origin IP、开入站防火墙口、到处配 NAT 和端口转发这些杂事。它还能把 HTTP、HTTPS、TCP、SSH、RDP 等应用放进同一条受控路径里。

Access 则不是给网站套一个登录框这么简单。它真正解决的是“这台机器上的这个应用，应该允许谁、在什么条件下、从什么身份体系进来”。如果你已经有 GitHub、Google、Okta 之类的身份源，Access 往往比自己手写一套管理后台更干脆。

Tunnel 解决的是门，Access 解决的是人

这两者经常一起出现，但职责完全不同。Tunnel 更接近网络层和连通性问题，回答的是“服务怎么被找到”。Access 更接近身份和策略问题，回答的是“谁被允许打开这个服务”。

这套东西最常见的落地方式

这也是为什么这章不要写成术语堆砌。对读者更重要的不是 Cloudflare 的名词分类，而是判断顺序：先看你是不是在暴露源站，再看你是不是要管访问者，最后才看你是否需要整套 Zero Trust 编排。

适合谁

常见误解

别把 Tunnel 想成通用 VPN。它更适合把具体应用、具体端口、具体服务收进 Cloudflare 的控制面里，而不是把所有内网协议都优雅搬到公网的万能胶水。

Access 也不是公共网站的默认加锁工具。凡是本来就应该对所有人开放的内容，你硬塞一个身份门槛，只会把体验变差。真正适合它的，是后台系统、预发布环境、管理控制台、内测服务这些“本来就不该裸奔”的东西。

边界在哪里

如果你只是要给一台机器开一个简单公开站，Tunnel 可能就够了。如果你只是要限制访问者身份，Access 也可能就够了。只有当你开始把身份、设备、网络位置和应用策略放在一起想，Zero Trust 才真正进入主线。

如果你希望的是完整的传统 VPN 体验，或者要把很多协议都当成“像在本地网里一样”去处理，也别把 Tunnel 当成万能替代品。它的重点是把资源安全地接进 Cloudflare，而不是替你重做一套私有网络世界。

核心建议：先想清楚“服务怎么连进来”和“人怎么进来”，再决定要不要上整套 Zero Trust。顺序对了，很多配置都会简单不少。

很多人第一次看 Workers，会把它理解成“边缘函数”。这句话不算错，但只说对了一半。更准确的说法是，Workers 是 Cloudflare 的主运行时：请求先到这里，判断先在这里做，后面的存储、协调、消息和 AI 能力，也大多从这里挂出去。

如果把 Cloudflare 看成一套平台，Workers 就是那根主轴。它不是单纯为了“写函数”存在，而是为了让请求时逻辑、边缘编排和产品绑定放在同一个地方。先把这一点看懂，后面读 R2、D1、Durable Objects、KV、Queues，都会顺很多。

主表

它解决的问题

Workers 解决的不是“能不能跑代码”这么简单，而是“请求来了以后，谁来把事情收口”。它适合做这些事：

• 接住外部请求。
• 在边缘做鉴权、重写、拼装和分流。
• 把文件、数据、状态、消息交给更合适的产品。
• 把原来厚重的应用服务器拆薄。

这也是它和传统服务器最大的区别。Workers 不是让你再搭一台机子，而是让你把每次请求当成一次短促、明确的计算。状态该放哪，就放哪，不要留在请求里硬撑。

什么时候该用，什么时候别用

和相邻产品的关系

常见误解

• 误解一：Workers 就是“边缘版后端框架”。其实它更像平台里的运行时底座。
• 误解二：只要能写代码，就该把所有逻辑都塞进 Workers。其实很多逻辑应该去 D1、R2、DO、KV 或 Queues。
• 误解三：Workers 和 Pages 是两条互相替代的路。其实它们更多是发布路径和运行时边界不同。

边界在哪里

• Workers 负责计算，不负责长期存储。
• Workers 负责编排，不负责把每一类状态都硬做成一个容器。
• Workers 适合短促、明确的请求逻辑，不适合把应用服务器整套思路搬进来。

核心建议：先把 Workers 当成请求入口和业务编排层，再决定要不要接 D1、R2、DO、KV、Queues。不要反过来。

站点最容易被低估的问题，不是“能不能上线”，而是“上线之后，代码和资源到底放哪”。在 Cloudflare 里，这个问题通常有两条路：Pages 偏站点交付，Workers 加 Static Assets 偏请求逻辑先行的应用。

别把它们看成重复产品。Pages 解决的是 Git 驱动的发布和预览，Workers 解决的是请求时计算，Static Assets 解决的是把静态资源跟 worker 项目绑在一起。三者不是一条线上的同一个按钮，而是三种不同的落点。

主表

先分清发布路径和运行时路径

如果你最关心的是构建、预览、回滚和把前端站点稳定发出去，Pages 往往更顺手。它围绕站点交付去设计，读者一旦把它看成“Git 驱动的发布链路”，就很容易理解它的价值。

如果你的项目从一开始就是请求逻辑先行，比如 API 驱动的应用、前后端边界很薄的工具、或者需要边缘判断的产品，Workers 往往更自然。这个时候 Static Assets 的意义就很大：静态资源不用再跟逻辑拆成两套系统。

什么时候该用，什么时候别用

Pages、Workers、Static Assets 的关系

常见误解

• 误解一：Pages 只是静态网站托管。实际上它能覆盖更完整的站点交付流程。
• 误解二：Workers + Static Assets 是 Pages 的重复版。其实它更偏请求逻辑优先的应用形态。
• 误解三：Static Assets 可以替代文件存储。它只管应用资源，不管长期业务文件。

边界在哪里

• Pages 解决“站点怎么发”。
• Workers 解决“请求时怎么做事”。
• Static Assets 解决“资源怎么跟代码一起发”。

核心建议：先判断你要的是站点发布，还是请求编排。前者优先看 Pages，后者优先看 Workers，资源跟应用绑定时再看 Static Assets。

如果你的问题是“文件放哪最合适”，R2 往往是 Cloudflare 里最先该看的答案。它的定位很直接：对象存储。也就是说，它适合放图片、视频、压缩包、导出文件、用户上传件、构建产物这些一眼就知道是 blob 的东西。

很多人喜欢 R2，不只是因为它像存储桶，更因为它把“文件在别处，应用在这里”这件事处理得很顺。Workers 负责接住请求，R2 负责稳稳地放文件，D1 负责元数据。边界一旦分开，很多系统会立刻变清楚。

主表

它解决什么问题

R2 解决的是文件存取和分发，不是关系建模。你只要开始按“这是一个对象吗”来思考，判断通常就会很快：

• 是文件，就先看 R2。
• 是结构化业务数据，就先看 D1。
• 是热状态和协调，就先看 Durable Objects。
• 是读多写少的键值配置，就先看 KV。

R2 的强项在于把对象稳稳放住，再让 Workers 去决定谁能读、谁能写、什么时候下载、什么时候转发。

什么时候该用，什么时候别用

R2、D1、KV 的边界

常见误解

• 误解一：R2 就是缓存。不是，它是持久对象存储，缓存只是可选层。
• 误解二：R2 就是数据库。不是，它没有关系型查询那套手感。
• 误解三：R2 适合塞所有业务文件。不是，文件之外的元数据和状态应该分出去。

边界在哪里

• R2 负责对象，不负责查询。
• R2 负责持久文件，不负责协调逻辑。
• R2 可以跟 Workers 组合得很顺，但不应该把业务系统的所有责任都揽过去。

核心建议：先判断你要处理的是文件还是数据。是文件就看 R2，是数据就看 D1，是状态协调就看 Durable Objects。

D1 最容易被误解成“Cloudflare 版数据库”，但这句话太粗了。更准确的说法是，它是一类托管的、无服务器的 SQLite 语义数据库，适合把轻量业务数据放在离应用很近的位置。

这也意味着，D1 不是拿来替代所有数据库系统的。它真正擅长的，是让你在 Workers 主导的应用里，快速拥有一个可读、可写、足够顺手的结构化数据层，而不是逼你先搭一整套传统数据库架构。

主表

它解决的问题

如果你的数据天然是表结构，有查询、有筛选、有少量关联，偶尔还要跑事务，D1 会比把东西全塞进 KV 或 R2 自然得多。你不用为了一个小型业务状态去上重型数据库，也不用把原本就是结构化的数据硬扁成 JSON。

D1 的价值不是“数据库更多”，而是“数据库够近”。它把常见业务的结构化数据留在 Cloudflare 这条主线上，和 Workers 一起形成一个很轻的应用骨架。

什么时候该用，什么时候别用

D1、KV、R2、Durable Objects 的边界

常见误解

• 误解一：D1 可以直接替代所有数据库。不是，它只适合边界清楚、体量合适的场景。
• 误解二：只要是数据，就应该放 D1。不是，文件先看 R2，状态协调先看 DO，轻配置先看 KV。
• 误解三：D1 只是一层包装。不是，它是让 Workers 侧的结构化数据更顺手。

边界在哪里

• D1 负责结构化数据，不负责文件。
• D1 负责轻量 SQL，不负责大规模分析仓库。
• D1 负责“够用且贴近”，不是“接管全部数据问题”。

核心建议：先看你的问题是不是表结构。如果是，D1 通常比硬塞 KV 或 R2 更对路；如果不是，就别让它背错责任。

如果说 Workers 是 Cloudflare 的主运行时，那 Durable Objects 就是这条主线里最容易让人卡住、但也最能拉开差距的能力。它不是数据库，也不是缓存，更不是给架构图贴标签的高级名词。

它真正解决的问题只有一个：当很多请求必须围着同一份状态转，而且还不能乱序、不能打架、不能互相覆盖时，你需要一个明确的协调点。聊天房间、多人协作、实时通知、游戏房间、分布式锁、计数器、会话协调，这些东西都不是“读写表”那么简单。

主表

它为什么存在

传统无状态函数最舒服的地方，在于每个请求都可以独立处理。但现实里的很多产品偏偏不是这样。总有人要在同一个房间里看见同一份在线状态，总有人要知道这一步是不是已经发生过，总有人要保证多个动作按一个顺序落地。

Durable Objects 的价值就在这里。它把这类问题从分布式系统里最难的部分收回来，让你围绕一个有身份的对象编程。很多本来要靠外部锁、轮询和补偿逻辑才能凑出来的东西，终于能自然地写出来。

什么时候该用，什么时候别用

它和相邻产品的关系

常见误解

• 误解一：Durable Objects 是数据库。不是，它是协调状态的原语。
• 误解二：只要用了 DO，系统就一定更快。不是，它的价值在一致性和顺序，不在所有场景的性能。
• 误解三：DO 适合替代一切后端状态。不是，文件、关系数据、异步消息都应该留给更合适的产品。

边界在哪里

• DO 负责收口共享状态，不负责大规模查询。
• DO 负责在线协调，不负责长期批量仓储。
• DO 的门槛高，不是因为概念难，而是因为它逼你重新想状态应该放哪。

核心建议：只要你的问题开始出现“并发就会乱”，就该认真看 Durable Objects。它贵，但贵得有理由。

很多人上 Cloudflare，最先学的是 Workers。再往后走，真正会卡住的往往不是计算，而是三件更琐碎的事：配置放哪，后台活怎么拆，长流程怎么不丢。

这时候，KV、Queues 和 Workflows 就会一起冒出来。它们名字都很短，但解决的问题完全不一样。最容易犯的错，是把它们都当成“后端存储”或者“任务系统”，然后开始乱塞。

主表

先把三者分开看

这三者不应该互相替代。

• KV 负责“读什么快、写什么少”。
• Queues 负责“先收下来，再慢慢做”。
• Workflows 负责“后面的步骤要做稳，还要能继续跑”。

Cloudflare 官方把它们放在一起，不是因为它们相似，而是因为它们刚好覆盖了后端里最容易被混掉的三类活。

KV 什么时候该用，什么时候别用

Queues 什么时候该用，什么时候别用

Workflows 什么时候该用，什么时候别用

三者怎么选

常见误解

• 误解一：KV、Queues、Workflows 都是“后端存储”。不是，它们分别是键值层、消息层和流程层。
• 误解二：Workflows 只是更强的 Queues。不是，Queues 负责投递，Workflows 负责流程状态。
• 误解三：KV 适合所有状态。不是，读多写少才是它的主场。

边界在哪里

• KV 不负责强一致。
• Queues 不负责共享状态协调。
• Workflows 不负责简单消息投递。

核心建议：先分清你要的是键值、消息，还是流程。顺序一错，后面就会一直补洞。

很多人第一次想把 AI 接进产品里，脑子里想的不是“我要做一个大模型平台”，而是更具体的事，摘要、分类、抽取、翻译、图片理解、客服辅助。

Workers AI 就是冲着这种需求来的。它不是让你从零养一套模型基础设施，而是让你在 Cloudflare 的网络上直接调用推理能力，把 AI 放到离业务请求更近的地方。

它要解决的不是“我有没有一个 AI 平台”，而是“我能不能在同一条请求链路里，把推理先做掉，再把结果交回业务”。这也是为什么它更像推理层，不像控制层。

13.1 它擅长的不是炫技，而是贴身

官方文档把 Workers AI 讲得很直接，serverless GPU、全球网络、从 Workers、Pages 或 API 调用，都在同一条线上。

这件事的好处很实在：

• 你少了一层外部模型接入的复杂度。
• 你的 AI 调用和业务请求更容易放在一起做。
• 你能把推理、存储、路由和权限放到同一个控制面里。

对已经在 Cloudflare 上的项目来说，这种贴身感很值钱。你不需要先把流量搬去别的地方，再把结果搬回来。

13.2 什么时候它特别合适

Workers AI 最适合的，是那些模型能力够用、但业务又很在乎链路短的场景。

比如：

• 生成摘要和标签
• 文本分类和抽取
• 图片识别和审核
• 轻量问答
• 和边缘请求强相关的实时 AI 功能

如果你的站点、API、登录页、内容分发本来就跑在 Cloudflare 上，Workers AI 会显得特别顺。你可以直接把它接进 Worker，少很多中间层。

13.3 什么时候别硬上

这章也得说实话，Workers AI 不是所有 AI 项目的最优解。

如果你要的是最前沿、最复杂、最强 reasoning 的模型，或者你对某一家模型供应商有非常明确的依赖，直接用对应厂商的 API 可能更稳。
如果你需要很强的私有模型定制、特别重的微调流程，Cloudflare 也不是你唯一的选择。

它的强项是平台感，不是“所有模型都最强”。这两者差别很大。

13.4 它和控制层、检索层怎么分

很多人会把 AI 产品混成一团，其实最简单的拆法是四层。

Workers AI 只占第一层。它很重要，但它只是第一层。

13.5 和谁一起看最顺

Workers AI 最好和这几样一起看：

• Workers，用来接请求和编排业务逻辑。
• Vectorize，用来做检索和上下文召回。
• AI Gateway，用来统一管外部模型流量、缓存、限流和观测。
• Agents SDK，用来做有状态 agent。

如果你把它们拆开理解，就会觉得只是几个产品名；如果你把它们连起来看，才会发现 Cloudflare 想做的是一条从请求入口到推理到记忆的完整链路。

13.6 使用边界

别把 Workers AI 理解成“Cloudflare 上的免费 AI”。

它的定位是托管推理，不是无成本推理。模型 catalog 也会变，支持范围会变，具体能力和限制最好都按官方文档和当前产品页来判断。写产品方案的时候，尽量不要把某个具体模型名写死成架构前提。

真正稳的方式，是先决定你需要的是哪类能力，再看 Workers AI 能不能满足；而不是先看到一个模型名字，就把整个产品路线贴上去。

核心建议：Workers AI 适合做离业务最近的推理层，不适合被当成 AI 总控台。先想清楚你要的是“算”“管”“找”还是“串”，再决定要不要把它放进链路里。

这两个产品放在一起看最省事，因为它们正好卡在 AI 应用最常见的两道坎上。

第一道坎是，模型不知道你的业务资料。第二道坎是，模型调用一多，成本、延迟、稳定性和安全性就开始乱。

Vectorize 解决前半段，AI Gateway 解决后半段。

14.1 Vectorize 不是知识库，它是检索层

官方对 Vectorize 的描述很直白，向量数据库，适合语义搜索、推荐、分类、异常检测这类能力。它的核心不是“把文本存进去”，而是“把 embedding 存进去，再按相似度把相关内容捞出来”。

这意味着它更像上下文找回器，而不是原始资料仓库。

很多人会误会这一点，结果把整个文档硬塞成向量，然后指望它自己变聪明。其实不是。真正稳的做法是：

• 原文放在 R2、D1 或其他原始存储里。
• 向量放在 Vectorize 里。
• 查询时先捞相关片段，再交给模型总结或回答。

这样你的系统才知道“内容在哪”，而不只是“像不像”。

14.2 AI Gateway 管的是模型调用

AI Gateway 的角色更像一个代理层，放在你的应用和模型供应商之间。

它能做的事很实用：

• 缓存重复请求，减少重复调用
• 限流，控制成本和滥用
• 重试和 fallback，提升稳定性
• 观测，看看请求到底怎么走
• Guardrails 和 DLP，给 AI 流量加安全检查

如果你同时接 OpenAI、Anthropic、DeepSeek 或别的供应商，AI Gateway 的价值会更明显。它把本来分散在各个 SDK 里的控制逻辑，收拢到一个地方。

14.3 它们为什么不在同一层

最容易犯的错，是把 Vectorize 和 AI Gateway 都叫成“AI 基础设施”，然后就开始混用。

其实它们面对的是两类完全不同的问题：

这就是橙皮书里最该讲透的地方：一个负责“找”，一个负责“管”。

14.4 这两个怎么配最自然

一个常见的 AI 应用链路可以这样搭：

1. 原始资料进 R2 或 D1。
2. 资料切片后生成 embeddings。
3. embeddings 存进 Vectorize。
4. 用户提问时先从 Vectorize 找上下文。
5. Worker 把上下文和问题发给模型。
6. 模型调用走 AI Gateway，统一做缓存、限流和审计。

这样拆完，你就不会把所有问题都压在模型本身上。

14.5 什么时候 Cloudflare 这条路最划算

如果你的应用本来就在 Cloudflare 上，或者你想把 AI 调用也收进同一个边缘平台，这条路很顺。

尤其在这几类场景里更明显：

• 有 RAG 需求
• 有多模型或多供应商接入
• 有缓存和成本控制诉求
• 有合规、审计、DLP 之类需求
• 有全球用户，想少一点跨地域抖动

这时 Vectorize 和 AI Gateway 放在一起，会比单独拼一个外部检索服务加一层自建代理省心很多。

14.6 使用边界

别把向量检索当成真理，也别把 Gateway 当成魔法。

Vectorize 只能帮你找近似相关内容，不会替你判断答案对不对。AI Gateway 能帮你控流和控险，但它不能替你保证模型回答永远正确。
如果你的数据需要强过滤、强结构化查询，还是得回到 D1、R2 或别的业务存储。
如果你的模型调用本来就很简单，只有一个供应商、没有审计需求、也不在乎控制面，多加一层 Gateway 也未必值。

这两个产品都很有用，但都不是默认必选项。它们适合的是已经开始认真经营 AI 业务的人，不是刚试水的 demo。

核心建议：Vectorize 负责把相关内容找出来，AI Gateway 负责把模型调用管起来。先把“找”和“管”分开，系统就不会乱。

Agents SDK 是 Cloudflare 在 AI 这条线里最容易让人产生误解的产品之一。

很多人一看到 agent，就会先想到聊天机器人。但 Cloudflare 讲的不是一个聊天框，而是一个能记住状态、能调用工具、能维持连接、还能和其他流程协作的应用单元。

它不是模型层，也不是简单的 UI 层。更准确地说，它是把 agent 真正跑起来的编排层。

15.1 它为什么适合放在 Cloudflare

官方文档说得很清楚，Agents 运行在 Durable Objects 上。这个细节很重要。

Durable Objects 给了 agent 三样东西：

• 状态
• WebSocket 连接
• 调度和一致性

这意味着 agent 不再只是“一次请求一段输出”，而是可以变成一个持续存在的对象。对要做实时对话、任务编排、多人协作、人工介入的应用来说，这个模型非常顺手。

15.2 什么时候应该选它

如果你的产品已经超过了“问一句，答一句”的阶段，Agents SDK 就开始有吸引力了。

比如：

• 有长期记忆的客服或助手
• 需要工具调用的业务 agent
• 需要用户实时看到状态变化的交互
• 需要人工审批再继续执行的流程
• 需要把多个 agent 或多个步骤串起来的系统

这类系统最怕的不是“有没有模型”，而是“状态怎么保持”。Agents SDK 正好就是冲着这个痛点来的。

15.3 什么时候别急着上

如果你只是想做一个简单的聊天接口，或者一个批处理脚本，Agents SDK 可能有点重。

Cloudflare 的 agent 路线，强在状态化和实时性，不是强在“任何 AI 场景都要套一层 agent”。

你要是本来就只有单轮调用，没有工具，没有会话状态，也没有异步协作，直接用 Worker 或 Workflow 反而更清爽。不要为了显得现代，就把简单问题做复杂。

15.4 它和别的产品怎么分工

先把层次分清，整个链路会顺很多。

比较自然的搭配方式是：

• Workers 负责入口和业务路由。
• Workers AI 负责默认模型推理。
• AI Gateway 负责模型流量控制、缓存和安全。
• Vectorize 负责上下文检索。
• Workflows 负责长任务和后台步骤。
• Agents SDK 负责前台交互和状态。

换个说法，Agent 管的是“我和用户怎么持续对话、怎么调用工具”，Workflow 管的是“这件事怎么稳稳做完”。

15.5 Cloudflare Skills 放在开发链的哪一层

cloudflare/skills 不是 Agents SDK 的运行时组成部分，而是 Cloudflare 官方为 coding agent 准备的知识层和工具入口。它解决的是“开发 agent 怎样更准确地理解并操作 Cloudflare”，不是“用户态 agent 怎样持久运行”。

放在本章里看，它对应的是开发链里的“知识层”和“工具层”；Agents SDK 对应的则是应用里的“状态编排层”。两者经常一起出现，但职责不同。

15.6 状态与工具的边界

不要把 agent 的记忆当成系统真相。

Agent 状态适合承载交互过程，不适合替代业务主库。真正重要的数据，还是应该落到 D1、R2、外部数据库，或者更合适的系统里。工具权限也不该无上限扩张，越接近最小可用权限，系统越可控。

核心建议：Agents SDK 负责把状态型 agent 编排起来，cloudflare/skills 负责让开发链少走弯路。前者是应用运行层，后者是开发辅助层。

Browser Rendering 现在官方已经改叫 Browser Run 了，意思也更直白，跑一个真正的浏览器；Turnstile 则站在你的网站入口上，判断来的人是不是机器。

一个负责“去做”，一个负责“去挡”。

16.1 Browser Run 适合做什么

官方现在把 Browser Run 定位成在 Cloudflare 全球网络上运行 headless Chrome，主要场景是自动化、抓取、测试、内容生成。

它有两个常见用法：

• Quick Actions，像截图、PDF、markdown、抓取这类轻任务。
• Browser Sessions，通过 Puppeteer、Playwright、CDP 直接控制浏览器。

如果你的需求是让系统像浏览器一样去看网页、点按钮、拿内容、生成文档，Browser Run 很合适。
如果你只是本地写一个脚本偶尔跑一下，很多时候本地 Playwright 就够了，不一定非要上 Cloudflare。

16.2 Browser Run 的两种用法

Browser Run 不是只给测试用，它也能给自动化 agent、内容抓取、批量检查和网页工作流提供真正的浏览器环境。

16.3 Turnstile 解决的不是“验证码”，而是入口摩擦

Turnstile 的设计比老式验证码轻很多。它的流程也很明确，前端挂 widget，服务端拿 token 去 Siteverify 验证。

官方还特意强调了一点，Turnstile 是独立服务，不要求你的网站一定经过 Cloudflare 代理。也就是说，你可以把它当成一个跨部署环境都能用的 bot 防护层。

这让它很适合：

• 登录
• 注册
• 评论
• 表单提交
• 其他容易被滥用的入口

它的价值不是把用户拦得很痛，而是尽量少打扰正常人。

16.4 Turnstile 的几种 widget 方式

16.5 这两个产品怎么一起理解

很多人会把它们混成“浏览器自动化和反爬”，其实不是。

• Browser Run 是给你自己或你的 agent 用的浏览器。
• Turnstile 是给访问你网站的人用的门禁。

前者帮你提高自动化能力，后者帮你降低垃圾流量和滥用。

如果你正在做 AI agent 或自动化系统，这个组合尤其有意思。Browser Run 可以让 agent 去执行网页任务，Turnstile 则可以保护你的用户入口不被机器刷爆。

16.6 什么时候 Cloudflare 这条路更合适

如果你本来就在 Cloudflare 上部署应用，或者你需要把浏览器自动化接进 Workers、Agents、内容抓取、测试流水线，这条路很顺手。

Turnstile 也一样。如果你想要的是低摩擦、云端托管、前后端都能清楚理解的 bot 防护，Turnstile 比自己拼一套复杂风控更轻。

但如果你已经有一套很成熟的浏览器农场、内部抓取平台，或者已有强风控体系，那就不一定值得全换。Cloudflare 这里更像是一个好上手、好集成的选项，不是唯一选项。

16.7 上线前先补这张表

Browser Run 负责把浏览器搬到云边，Turnstile 负责把门守住。两者都适合放进生产链路，但都需要把最后一层验证和限额补齐。

核心建议：Browser Run 是执行层，Turnstile 是入口层。一个让你的系统能动起来，一个让你的入口别被刷烂。

很多人学 Cloudflare 的顺序是反的：先背产品名，再问自己该把什么放进去。更顺的办法不是先选工具，而是先看应用形状。形状对了，拼法就顺；形状不对，单个产品再强也会被你用得很拧巴。

17.1 先看主表

17.2 这四种拼法解决什么

Cloudflare 真正擅长的，不是把所有后端问题都变轻，而是把“入口、分发、文件、状态、异步”拆到各自更合适的位置。

• Pages 负责把站点和前台先发出去。
• Workers 负责请求处理、API、鉴权、聚合和胶水逻辑。
• R2 负责对象、附件、导出包和大文件。
• D1 负责轻量关系数据。
• Durable Objects 负责串行化状态和并发协调。
• Queues 负责把慢任务移出主请求。
• Workflows 负责把多步骤流程接住并记住进度。

真正有价值的不是“我能不能把全部产品都接上”，而是“我有没有把每一层都放到最合适的位置”。

17.3 什么时候该拆，什么时候别拆

17.4 和相邻产品的关系

最容易混淆的几组关系，可以直接记成一句话。

• Workers vs Pages：前者是运行时，后者是发布面。
• D1 vs Durable Objects：前者更像轻量关系数据库，后者更像状态协调原语。
• KV vs Durable Objects：前者适合读多写少的边缘配置，后者适合必须串行化的状态。
• Queues vs Workflows：前者负责传消息，后者负责跑流程。

17.5 常见误解

很多人会把 Cloudflare 理解成“把一切都边缘化”。这句话只对一半。

它更准确的意思是：你可以把适合入口和分发的东西放到边缘，把适合协调和持久化的东西放到更合适的原语上。不是所有东西都要上边缘，也不是所有东西都应该留在传统后端。

核心建议：先按应用形状选拼法，再按产品能力做微调。不要反过来。

看 Cloudflare 成本，先别只盯单价。真正会拉高成本的，通常是请求链路、状态模型、外部依赖和运维治理一起叠上来。

18.1 先看主表

18.2 免费入口与付费方式

下面这两张表对应 2026 年 4 月 17 日查阅的 Cloudflare 官方定价页口径。数字和计划会调整，但“先用什么免费层起步、后续按什么维度收费”这两件事最值得先记住。

18.3 读这两张表时先拿到四个判断

18.4 架构对账单的影响

Cloudflare 很适合小团队的一点，是它能把不少基础设施成本前移成平台成本。你不用自己养机器、补证书、维护入口层，很多时候也不用先买一堆固定容量。

但这不代表“便宜”会自动发生。更准确的说法是：Cloudflare 把一部分成本从运维变成了使用量和设计约束。你越接近平台习惯，越省；你越想把它当传统后端拼装，越容易在体验上感觉别扭。

18.5 常见成本症状与处理顺序

18.6 常见限额类型

Cloudflare 的很多能力都带着明确限制。这里不建议死背具体数字，因为这些值会变；更重要的是知道限制大致分哪几类。

• 执行时间和 CPU 时间。
• 请求次数、子请求次数和调用链复杂度。
• 存储和对象生命周期。
• 队列吞吐、并发和重试。
• 日志保留、观测采样和导出频率。

这些限制不一定是问题。很多时候它们只是在提醒你：这不是一个适合重型长事务或超长后台批处理的平台。模型换对了，限制反而会逼你写出更干净的系统。

18.7 冷启动常见来源

大家说“冷启动”时，往往把几个完全不同的问题混在一起了。

有一种冷启动，是真正的运行时启动。Cloudflare 这种边缘平台在这方面通常比传统容器平台轻，因为它不需要你管理一大堆固定实例。

但更常见的冷启动，其实是依赖冷启动：数据库连接慢、外部 API 慢、对象存储读写慢、一次请求里又查库又打第三方又写日志。你以为自己怕的是 runtime，其实怕的是链路。

18.8 不适合放进 Cloudflare 的系统

Cloudflare 不是不能做大系统，而是有些系统天生不该硬塞进边缘模型。

如果你需要很复杂的长事务、强一致多写、重型批处理、深度内网拓扑，或者你的业务本身就依赖一整套传统云上的运行假设，那继续往 Cloudflare 上硬拽，通常会让工程复杂度上升，而不是下降。

核心建议：先改模型，再看成本。不要先把问题理解成“单价贵不贵”，而是先问“这个链路是不是本来就写错了”。

很多团队一开始用 Cloudflare 时都很开心：部署快，入口统一，功能也够用。真正开始出问题，是项目从“个人可维护”变成“多人共用”之后。这个时候，最值钱的就不再是功能本身，而是你能不能看见问题、定位问题、限制权限、管住发布。

19.1 先看主表

19.2 观测这件事要先分层

观测最怕把所有信号混成一锅。更顺手的做法是把它拆成三层。

• 请求发生了什么。
• 业务逻辑做了什么。
• 团队发布和配置改了什么。

Cloudflare 的控制台、Workers observability、日志导出、GraphQL analytics、WAF 事件、Turnstile 统计、缓存命中率，分别回答的其实不是同一个问题。你如果一上来就只看一个大 dashboard，很容易知道“系统好像有问题”，但不知道问题在哪一层。

19.3 日志要能落地，不要只停在页面上

很多排障是靠日志，不是靠漂亮图。Cloudflare 的日志和观测能力足够做基础运维，但前提是你愿意提前设计。

比较实用的做法是：

1. 关键请求打上稳定的 request id。
2. 运行时日志和边缘请求记录能对上。
3. 对外部依赖、数据库、对象存储的错误做分类。
4. 真正需要长期留存的日志，走导出或集中存储。

如果只靠控制台现场看，你会发现一些问题很快就没了，因为时间窗口太短；如果完全不做日志规范，你会发现大家在复盘时只能靠猜。

19.4 权限不要共用大号

Cloudflare 这种控制台型平台，最容易出事故的不是技术，而是权限习惯。很多团队默认拿一个主账号干所有事，短期图省事，长期很危险。

这不是流程洁癖，而是后面真出事故时，你至少能知道是谁改了什么、改到了哪一层。

19.5 团队协作的最低标准

一套能长期跑的 Cloudflare 团队实践，不需要特别复杂，但至少要做到这几件事：

• 任何生产变更都能追到人和时间。
• 任何接口问题都能在日志里找到对应请求。
• 任何权限都尽量最小化。
• 任何高风险配置都不会只靠口头约定。

核心建议：Cloudflare 进入团队生产环境，不是靠“功能都开了”，而是靠“谁做了什么、出了什么事、怎么改回来”都能说清楚。

中国开发者看 Cloudflare，最容易犯的错，就是把“全球网络很强”直接等同于“在中国也同样顺手”。这两个判断不是一回事。前者说的是平台能力，后者说的是交付现实。

20.1 先把三条线放在一张表里

20.2 真正影响体验的，往往不是产品名，而是路径

很多人第一次碰到 Cloudflare 的中国问题，都会问“有没有国内节点”。这个问题不是完全错，但太粗了。

更现实的问题是：

• 你的用户主要在哪里。
• 你是否真的要在中国大陆正式交付。
• 你能不能接受企业订阅和备案流程。
• 你要的是体验优化，还是正式网络路径。

一旦这几个问题问清楚，很多争论就会少很多。因为你会发现，大家口中的“Cloudflare 中国方案”，其实说的是三件不同的事。

20.3 中国开发者最适合的判断方式

20.4 别把优选节点写成神话

社区里常说的优选节点，本质上是在变化的网络条件里挑一个更顺手的 Anycast 入口。它确实可能改善体验，也确实有现实价值，但它不是官方交付。

更重要的是，它不是稳定边界。运营商策略会变，Cloudflare 路由会调，地区差异会抖，某个今天好用的入口，下个月未必还在同一个位置上表现最好。

20.5 判断顺序

Cloudflare 在中国语境里最重要的不是“能不能用”，而是“你现在走的是哪条线”。

默认全球网络、官方 China Network、社区优选路径，这三条线在成本、稳定性、合规性和可持续性上都不是一个层级。先把路径判断清楚，后面的产品选择才站得住。

核心建议：先说清用户在哪里，再说清你要哪条路径。不要把三条线混成一句“Cloudflare 在中国能用吗”。

如果只看名字，很多人会把 China Network 理解成“Cloudflare 在中国的加速开关”。这个理解太轻了。更准确的说法是：它是一条官方的中国大陆交付路径，解决的是正式落地、合规准备和可用能力边界的问题。

21.1 先看主表

21.2 它解决的不是“偶尔快一点”

China Network 的核心价值，不是让你今天测速跑分更漂亮，而是让你在中国大陆有一条明确的、官方定义的交付路径。

这意味着几件事：

• 它不是默认账号自带的附属功能。
• 它不是全球网络自动在中国变形后的结果。
• 它不是一个把所有 Cloudflare 产品原样复制到中国的镜像层。

很多人真正需要的，其实是“我能不能认真地把业务交给一条可预期的官方路径”。China Network 就是为这件事准备的。

21.3 开通前先接受它的前提

官方文档对前提写得并不含糊。想走这条路，通常要先接受这些现实：

• 你需要 Enterprise 计划，并额外订阅 China Network。
• 你需要准备有效的 ICP 备案或许可证。
• 你的网站首页需要展示 ICP 编号。
• 你的域名和内容会经历审核和 vetting。

这些前提看起来门槛不低，但它们也说明了一个很现实的事实：China Network 不是消费级开关，而是面向正式业务交付的企业路径。

21.4 它的能力是子集，不是全量平台镜像

这点很重要，很多介绍都写得太轻。China Network 的可用能力要以官方 available products 页面为准。换句话说，你不能默认全球平台上有的能力，在中国路径里就一定同样存在。

正确理解方式是：

• 有些能力在中国路径里可以直接用。
• 有些能力有额外条件。
• 有些能力需要看官方文档里的边界说明。

这意味着设计中国业务时，不能先拍脑袋说“Cloudflare 全家桶都能搬进来”。你得先看产品子集，再决定哪些链路适合放进去。

21.5 什么时候 China Network 是正确答案

如果你的业务明确面向中国大陆用户，且你需要的是正式交付、合规准备和长期可维护的官方路径，那 China Network 是该认真评估的方案。

它最适合的，不是“临时试试看”，而是这种问题：

• 我们是不是要把中国大陆交付做成正式业务能力。
• 我们能不能接受企业订阅和备案流程。
• 我们是否需要一个可以长期依赖的官方网络路径。

21.6 什么时候它不是答案

如果你的业务主要是海外用户，或者中国只是次要流量来源，那未必值得先走这条复杂路径。很多时候，先把全球默认网络和基础缓存策略做好，收益已经足够大。

如果你只是想让某个访问点“看起来更快一点”，那也未必需要直接上 China Network。因为你真正想解决的，可能只是体验优化，而不是正式交付。

核心建议：China Network 的关键词不是“更快”，而是“官方、企业、可交付”。先按这三个词判断，再谈要不要上。

社区优选节点这件事，很多人都听过，但不一定说得准。它真正对应的，不是某种神秘加速术，而是一个很朴素的事实：Cloudflare 的入口是 Anycast，但不同地区、不同运营商、不同时间段，实际走到用户那里的路径不一定一样。

22.1 先看主表

22.2 这类社区路径在做什么

所谓优选 IP、优选节点，通常就是通过测速、下载测试或延迟筛选，在一组入口里挑出当前更顺手的那个。XIU2/CloudflareSpeedTest 这类工具就是典型代表。

这类方法能起作用，不是因为它改造了 Cloudflare，而是因为它在“同一个 Anycast 体系里挑相对更合适的入口”。这件事对某些网络环境很有用，尤其当你只是想让访问体感好一点的时候。

22.3 它能解决的，通常只是体感问题

优选节点适合处理的，更多是这些情况：

• 个人网站偶发访问慢。
• 某个地区、某个运营商下体验不稳定。
• 你想临时选一个相对更顺手的入口做测试。

它能帮你缩短某些访问路径，但它并没有改变 Cloudflare 的产品边界，也没有让你的业务自动获得一条正式的中国大陆交付路径。

22.4 它不能替代什么

这一点一定要写清楚。优选节点不能替代：

• 官方 China Network。
• ICP 和备案要求。
• 正式的产品可用性边界。
• 长期可依赖的合规交付方案。

如果你的业务是正式在中国大陆交付，这类社区方案只能算经验参考，不能算架构答案。它更像临时体感优化，而不是交付方案。

22.5 什么时候可以用

如果你做的是个人项目、海外为主的产品、轻量内容站，或者你只是想在某些网络环境下做一个现实的优化尝试，优选节点可以被理解、可以被测试。

但它的使用方式最好保持克制：

• 只把它当成体验优化手段。
• 只把它当成阶段性观察结果。
• 不要把某次测速当成长期结论。

22.6 怎么写才不神化

最稳妥的写法，是把优选节点放回它本来的位置：它是社区经验，不是官方产品；它可能有用，但不保证长期稳定；它能改善体感，但不能替代正式路径。

这也是为什么这类话题可以聊，而且值得聊，但不能被写成“Cloudflare 在中国的问题已经被解决了”。没那么简单。

核心建议：社区优选路径只能当临时优化和测试手段。只要涉及正式中国交付，就必须回到官方路径和合规边界。

这份附录把学习顺序压缩成几张速查表，方便按角色和场景快速定位。

最短学习路线

快速判断表

学习顺序

Pages -> Workers -> R2/D1 -> Durable Objects -> Observability -> China Network

这条线够短，也够实用。先顺着它走，后面再补产品细节，学习效率会高很多。

下面只保留长期最值得回看的官方入口和少量社区工具。

先看入口

按主题看

长期回看的官方页

Agent 开发入口

少量社区参考

资料使用顺序