从零读懂 Cloudflare

本文用「连锁便利店」的生活化类比，从零拆解Cloudflare的底层逻辑、全产品线与实战场景，讲透静态/动态资源、CDN、边缘节点、边缘函数等核心技术概念，附带微信小程序后端完整实战案例与新手避坑指南，零基础也能轻松看懂并上手。

前言：为什么你每天上网，都绕不开这家公司？

你可能从没听过Cloudflare的名字，但你每天刷网页、看视频、用小程序、逛电商的时候，大概率已经无数次和它打过交道。

它不像微信、淘宝那样出现在你的手机桌面，也不像阿里云、腾讯云那样经常出现在新闻里。它更像城市地下的水管、电网、高速公路——你看不见它，但它一旦出问题，半个互联网都会跟着瘫痪。2025年的一次全球故障，让ChatGPT、X（原推特）、Discord等数万个网站集体打不开，全网用户集体懵圈，罪魁祸首就是Cloudflare的一次配置失误。

一家公司故障，半个互联网跟着宕机，它凭什么有这么大的能量？它到底是做什么的？为什么全球几千万个网站都要用它？我们常听的CDN、边缘计算、DDoS防护、边缘函数，到底是什么意思？普通开发者、个人博主、小程序创业者，能用它干什么？它真的是“免费白嫖神器”吗？有哪些坑是新手必踩的？

这篇文章，我会全程用「连锁便利店」的生活化类比，把所有晦涩的技术术语拆解得明明白白。不需要你懂编程、不需要你有服务器基础，看完你就能彻底搞懂Cloudflare，甚至能上手用它做自己的小程序后端、搭个人博客、建免费图床。

全文从公司背景到底层原理，从全产品线到实战场景，从新手避坑到未来趋势，一次性给你讲透。

第一部分 Cloudflare的前世今生：从反垃圾邮件项目到全球互联网底座

很多人以为Cloudflare是近几年才火的“新公司”，其实它已经走过了15个年头。它的诞生，起源于一个看起来和“互联网基建”毫不相干的问题：垃圾邮件从哪来？

1.1 故事的起点：一个追踪垃圾邮件的校园项目

时间倒回2004年。那时候的互联网还是蛮荒时代，网站最头疼的问题之一就是垃圾邮件泛滥——爬虫会在全网爬取公开的邮箱地址，然后批量发送垃圾广告、诈骗邮件，防不胜防。

当时还是技术工程师的马修·普林斯（Matthew Prince） 和程序员李·霍洛威（Lee Holloway） 突发奇想：能不能做一个系统，追踪这些爬虫是从哪来的、怎么收集邮箱的？他们给这个项目起了个很形象的名字：蜜罐项目（Project Honey Pot） ——就像放一罐蜂蜜在地上，吸引蚂蚁过来，然后观察蚂蚁的巢穴在哪。

这个项目完全免费，任何网站都可以接入。没想到一下子火了，短短几年里，全球185个国家的几千个网站都加入了进来。大家一起贡献数据，慢慢画出了一张全球“恶意行为地图”：哪些IP地址是爬虫、哪些是垃圾邮件发送者、哪些经常搞破坏，全都一清二楚。

用了几年之后，用户们开始反复提同一个需求： “你们光追踪坏人有什么用？能不能直接把他们挡住？”

对啊，只诊断不治疗，治标不治本。但当时的网络安全产品是什么样的？贵。一套硬件防火墙几十万，只有大公司才买得起。难。需要专业的运维团队部署调试，小网站根本玩不转。慢。攻击来了才反应过来，网站早就被打挂了。

普林斯和霍洛威意识到：这里面藏着一个巨大的机会。能不能做一个云端的、一键接入的、便宜甚至免费的安全防护服务，让小网站也能用上企业级的安全能力？

1.2 三个创始人的碰撞：技术+商业的完美组合

想法有了，但光有技术还不够，得有人把它变成生意。 2009年，普林斯去哈佛商学院读MBA，在课堂上认识了来自加拿大的女生米歇尔·扎特林（Michelle Zatlyn）。两个人聊天的时候，普林斯聊起了蜜罐项目和他想做“云端防火墙”的想法。

扎特林眼睛一下子亮了。她敏锐地察觉到，这不仅仅是一个安全工具，而是能改变整个互联网基础设施的生意。两个人一拍即合，开始在宿舍里写商业计划书。

他们给项目起的第一个名字很直白，叫「Project Web Wall」——网页之墙。但总觉得不够酷，像个硬核的技术工具，没有记忆点。后来普林斯的一个朋友建议：你们做的是“云端的防护火焰”，不如叫 Cloudflare？云（Cloud）+ 闪耀/防护（Flare），既有科技感，又点明了“云端防护”的核心。三个人一听，当场就定了这个名字。

2009年夏天，他们拉上最初的技术合伙人李·霍洛威，三个人正式成立了公司。

马修·普林斯：CEO，负责战略和对外，是公司的门面
李·霍洛威：CTO，负责底层技术架构，是技术灵魂
米歇尔·扎特林：COO，负责运营和商业化，是大管家

这是一个堪称完美的创始组合：有技术、有商业、有运营。三个人各司其职，带着一个想法、一个原型，开始了创业之路。

1.3 从哈佛商业计划冠军到正式上线

2009年4月，他们带着Cloudflare的商业计划，参加了哈佛商学院的创业大赛，一路过关斩将拿了冠军。这次获奖给他们带来了第一波关注，也吸引了投资人的目光。

同年11月，Cloudflare拿到了210万美元的A轮融资，公司正式运转起来。但真正的考验才刚刚开始。当时CDN和安全市场，已经有了巨头Akamai、F5 Networks，它们做的都是百万级的企业生意，一套服务几十万起步。而Cloudflare想做的，是让个人站长、小公司也能用得起，甚至免费。

这个想法在当时看来简直是疯了。 CDN和安全服务极其烧钱——要在全球建节点、买服务器、租带宽，成本高得吓人。免费给用户用，怎么赚钱？

但Cloudflare走了一条完全不同的路： 软件定义一切。 传统厂商靠专用硬件，一台设备几十万；Cloudflare用通用服务器+自研软件，一台普通服务器就能跑所有服务，成本一下子降了下来。 全球共享资源池。 所有用户共享全球节点的带宽和算力，攻击来了全网络一起扛，成本被摊薄了。 免费版引流，付费版盈利。 个人用户和小网站用免费版，既能扩大市场份额，又能收集更多威胁数据，让安全系统更聪明；中型企业和大公司买付费版，享受更高级的功能和服务。

2010年9月27日，在全球知名的科技大会TechCrunch Disrupt上，Cloudflare正式对外发布。上线第一天，就有上千个网站注册。谁也没想到，这个从宿舍里走出来的项目，会在未来十几年里，重塑整个互联网的基础设施。

1.4 十五年进化之路：从CDN厂商到连接云平台

如果把Cloudflare的发展分成三个阶段，你就能清晰看到它的野心：

第一阶段（2010-2015）：安全+加速的基础服务商

早期的Cloudflare，核心产品就是两个：

DDoS防护：帮网站挡住攻击
CDN加速：让网站打开更快

这时候它的定位很清晰：给网站做“加速+安全”的外挂。你把网站服务器放在任何地方，只要把DNS解析改到Cloudflare，就能一键获得加速和防护。这个阶段的Cloudflare，更像一个“网站保镖+快递加速员”。

第二阶段（2016-2020）：边缘计算平台的崛起

2017年，Cloudflare发布了划时代的产品：Cloudflare Workers。在此之前，边缘节点只能存东西、转发请求，不能跑代码。Workers第一次让开发者可以把自己的代码，部署到全球几百个边缘节点上，在离用户最近的地方运行。

这一步太关键了。它意味着Cloudflare不再只是“传输管道”，而是变成了“计算平台”。以前你想做个网站，必须买服务器、搭环境、运维；现在你写好代码，扔给Cloudflare，全球用户都能就近访问，你连服务器是什么都不用管。

紧接着，配套产品一个接一个出来：

2019年：Workers KV 边缘键值存储，能存数据了
2021年：R2 对象存储，免费出站流量，对标亚马逊S3
2021年：Pages 静态网站托管，对标Vercel、Netlify
2022年：D1 边缘SQL数据库，边缘也能跑关系型数据库了

到这个阶段，开发者已经可以完全不用传统服务器，只用Cloudflare全家桶，就能做出一个完整的网站、小程序后端、API服务。

第三阶段（2021-至今）：全球连接云（Connectivity Cloud）

近几年，Cloudflare的边界还在不断扩张：

企业端：推出Zero Trust零信任安全、Cloudflare One企业网络，帮公司做全球办公组网
AI端：推出Workers AI，在边缘节点跑AI模型推理，把AI能力下沉到用户身边
网络端：Magic Transit、Spectrum，把防护和加速能力从网页扩展到所有网络应用

现在的Cloudflare，已经不是单纯的CDN公司，也不是单纯的云计算公司。它的定位是全球互联网的连接层——用户、应用、数据、网络、设备，全都通过它来连接。

就像它自己说的使命：帮助建设一个更好的互联网（Help build a better Internet）。

1.5 今天的Cloudflare：全球互联网的隐形管家

15年过去，今天的Cloudflare已经成长为庞然大物：

全球节点：在125+个国家、335+个城市部署了数据中心，覆盖全球95%的互联网用户，平均延迟不到50毫秒
网络规模：和全球13000+家运营商、云厂商、企业网络直接互联，总带宽容量超过500Tbps
服务客户：超过23万家付费客户，其中3000多家是年付费10万美元以上的大企业，从个人博主到世界500强，都在用它的服务
市场地位：CDN市场份额全球第一，全球超过20%的网站都在使用它的服务

更厉害的是，它的所有服务，都跑在同一套通用服务器上。你在Cloudflare后台开一个WAF、开一个CDN、开一个Worker，底层都是同一批机器，只是软件功能不同。这种“软件定义一切”的架构，让它的成本极低，也让免费模式成为可能。

对于中国大陆用户，还有一个重要信息： Cloudflare在中国大陆不单独建节点，而是和京东云（JD Cloud）达成战略合作，由京东云提供国内的机房和合规资质，目前已经在国内35个城市部署了节点，覆盖一二线主要城市。也就是说，国内用户访问接入了Cloudflare的网站，请求会落到国内京东云合作的节点上，速度和合规性都有保障。当然，这只针对企业版的中国网络服务，免费版默认走的是境外节点，这个我们后面会详细讲。

第二部分先搞懂底层逻辑：互联网是怎么跑起来的？

在讲Cloudflare的产品之前，我们得先搞懂一个最基础的问题：你在浏览器输入一个网址，到页面显示出来，这中间到底发生了什么？为什么有的网站秒开，有的网站转半天圈？为什么有的网站好好的，突然就打不开了？

这一章，我们用「寄快递」的类比，把互联网的底层逻辑讲透。看懂了这个，后面所有概念你都能一学就会。

2.1 你打开一个网页的全过程：快递寄件的比喻

我们把「访问网站」类比成「你向远方的工厂定制一件商品」：

你（用户）：住在家里，想要买东西
手机/电脑：你的快递员，帮你跑腿下单和收货
网址（域名）：工厂的名字，比如“XX服装厂”
IP地址：工厂的实际物理地址，XX市XX区XX路XX号
DNS服务器：全国统一的地址本，你说工厂名字，它给你查具体地址
源服务器：工厂本部，所有商品都在这里生产、库存都在这里
网络链路：公路、高速、国道，快递在路上走的路
网页内容：你买的商品

好了，现在我们走一遍完整流程：

查地址 你说：“我要去淘宝买东西。” 你的快递员先打电话给地址本（DNS）：“淘宝的工厂地址在哪？” DNS查一下，告诉它：“杭州市余杭区文一西路969号。”
发请求 快递员带着你的订单，沿着公路往工厂跑。一路上可能要换好几次高速、过好几个收费站，绕很多弯路，才能到达工厂。
工厂处理 工厂收到订单，安排工人生产：

如果是现成的衣服（静态资源），直接从仓库拿一件
如果是定制的印字T恤（动态资源），要安排车间现做，还要查你的会员信息、积分

寄回来 工厂把做好的商品打包，交给快递员，再沿着公路送回你家。你收到货，拆开包装，网页就显示出来了。

这就是一次完整的网页访问过程。听起来很简单对不对？但现实中，这个过程会遇到各种各样的问题。

2.2 为什么网站会慢？距离远、路不好、仓库忙

你网购的时候肯定有体会：

从隔壁省发货，第二天就到；从东北发到海南，要等一个星期
遇上双十一爆仓，快递要在中转站卡好几天
工厂订单太多，生产不过来，发货延迟

网站慢，原因一模一样，主要有三个：

原因一：物理距离太远

这是最根本的原因。数据在光纤里传输，速度接近光速，但也不是无限快。从广州的用户电脑，发到北京的服务器，光跑单程就要大概30毫秒，一来一回就是60毫秒。如果服务器在美国西海岸，一来一回就要150-200毫秒。再加上中间经过的路由器、交换机的延迟，实际延迟会更高。你觉得几百毫秒好像不多，但一个网页要加载几十上百个文件，加起来就会慢好几秒。

就像你家在广州，工厂在哈尔滨。你买瓶矿泉水，也要从哈尔滨发过来，路上走三天。不是矿泉水生产慢，是路太远了。

原因二：网络路不好走

互联网不是一条笔直的高速公路，而是由无数张大小网络拼接起来的。数据从你的手机到服务器，中间可能要经过十几个运营商的网络、几十个路由器。有的路段宽、速度快；有的路段窄、堵车；还有的路段绕远路，明明可以走直线，偏偏要绕个大弯。

比如你用电信宽带，访问联通机房的服务器，就可能要绕很远的路，速度特别慢。就像快递本来可以走直达高速，结果被安排走省道、绕县城，自然就慢了。

原因三：服务器忙不过来

如果同时有太多人下单，工厂产能有限，就会排队。双十一的时候淘宝服务器压力大，页面加载慢；明星官宣微博的时候，服务器崩了，都是这个道理。工厂只有那么多工人，同时处理一万个订单没问题，同时来一百万个，肯定就炸了。

2.3 为什么网站会挂？黑客攻击和流量洪峰

网站打不开，除了慢，还有一种更严重的情况：直接挂了。常见原因有两种：

第一种：正常流量洪峰

比如突然上了热搜，一下子几十万人涌进来，服务器扛不住，直接宕机。这属于“幸福的烦恼”，是生意太好导致的。

第二种：恶意DDoS攻击

这是互联网上最常见的恶意破坏行为。简单说，就是黑客雇了几万、几十万台“僵尸电脑”，同时给你的网站发请求，就像雇了一群人堵在你工厂门口，疯狂下单、挤门口，把正门堵得水泄不通。正常用户的订单根本送不进去，工厂也没法正常干活，网站就相当于“被打挂了”。

这种攻击成本极低，打垮一个小网站可能只要几块钱。但传统的防御方法极贵：要租超大带宽、买专业清洗设备，一年几十万起步，小网站根本承受不起。

2.4 传统解决方案的痛点：贵、麻烦、效果差

面对“慢”和“不安全”这两个问题，传统的解决方案都不完美：

方案一：多买几台服务器，多建几个机房

比如你在广州、北京、成都、上海各建一个机房，用户就近访问。效果确实好，但成本爆炸：

每个机房都要买服务器、租带宽、雇人运维
数据还要在多个机房之间同步，技术难度极高
中小公司根本玩不起，只有巨头才玩得转

方案二：买传统CDN服务

CDN就是内容分发网络，简单说就是帮你在各地缓存静态文件。但传统CDN有几个问题：

贵，按流量计费，流量大了账单吓死人
只能加速静态资源，动态内容管不了
配置复杂，还要自己做缓存策略，新手根本玩不转

方案三：买硬件防火墙防攻击

一台高端DDoS清洗设备几十万，还要配专人维护。而且攻击流量超过你的带宽上限，防火墙再强也没用，因为门口的路已经被堵死了。

方案四：用云服务器

阿里云、腾讯云这些云厂商，确实降低了服务器的门槛。但本质上还是“你租一台远程电脑”，服务器还是集中在少数几个机房里，距离远的问题依然存在。而且云服务的带宽、流量费都不便宜，攻击防护还要额外加钱。

就在这个时候，Cloudflare带着它的全球边缘网络来了。它用一套全新的思路，把“加速”和“安全”这两件事，成本降到了几乎为零。

第三部分核心概念大白话：用连锁便利店讲透所有术语

这一章是全文的核心。我会用「社区连锁便利店」这个贯穿始终的类比，把静态资源、动态资源、CDN、边缘节点、边缘函数、Anycast这些听起来高大上的术语，全部讲得明明白白。

记住这个核心设定：

总部仓库（源站）：在很远的郊区，产能最大、货最全，但过去一趟很远
社区便利店（边缘节点）：开在每个小区楼下，离用户极近
货架商品（静态资源）：提前生产好的成品，拿了就走
定制餐食（动态资源）：必须现做，每个人的都不一样
便利店店员（边缘函数）：能处理简单业务，不用什么都找总部
统一客服电话（Anycast任播）：全国一个号码，自动接最近的店

看完这一章，你再看任何云计算、边缘计算的文章，都会觉得无比简单。

3.1 边缘节点：开在你家楼下的便利店

3.1.1 什么是“边缘”？互联网的最后一公里

我们常听“边缘计算”、“边缘节点”，很多人搞不懂“边缘”到底是哪。其实特别简单：互联网像一棵大树。

核心机房、大型数据中心，是树的树干和主根，在最中心
城市的汇聚机房，是大树的树枝
你家的路由器、你的手机，是树叶，在最外围

“边缘”，指的就是靠近用户这一侧、靠近树叶的位置。离用户越近，就越“边缘”；离核心机房越近，就越“中心”。

那“边缘节点”是什么？就是部署在网络边缘位置的服务器。它不在遥远的贵州数据中心，也不在内蒙古的机房里，而是就在你所在的城市，甚至就在你家附近的运营商机房里。

用便利店类比：

中心机房 = 郊区的总部大仓库
边缘节点 = 开在你家小区楼下的便利店

以前买东西，你要开车跑几十公里去总部仓库。现在楼下就有便利店，下楼就能买，速度自然快了无数倍。

3.1.2 边缘节点是谁的？房子租的，设备自己的

很多人问：Cloudflare在全球300多个城市都有机房，它买了300多栋楼吗？当然不是。我们把一个边缘节点拆开，它的产权分三部分：

组成部分	便利店类比	产权归属	通俗解释
数据中心机房	整栋商业楼	租用，不是Cloudflare的	Cloudflare不会买整栋机房楼，而是向全球各地的数据中心运营商租机柜空间（相当于租门面），按月付房租和电费，行业里叫「主机托管」。全球335个城市的节点，都是这种合作模式。
服务器硬件	店里的货架、收银机、空调设备	Cloudflare自有，自己设计采购	机柜里的服务器是Cloudflare自研定制、自己花钱买的，不是租机房的，也不是租其他云厂商的云服务器。这也是Cloudflare和普通云厂商最大的区别——它不做“机器转租”生意，而是用自己的硬件给你提供服务。
网络线路	门口的马路、配送通道	部分自建，部分合作	城市之间的长途骨干网，Cloudflare自己铺了一部分专用光纤；城市内的接入，大多是和当地运营商免费直连（对等互联），只有少部分是花钱买的带宽。

一句话总结：房子是租的，家电是自己的，路一半自己修一半和别人共用。

这种模式的好处是扩张极快。想在一个新城市开节点，只要找当地机房租几个机柜，把自己的服务器运过去插上网线，当天就能上线服务。这也是为什么它能在短短十几年里，铺到全球335个城市。

3.1.3 全球335个城市的便利店网络

截至2026年，Cloudflare在全球125个以上的国家、335个城市，都部署了边缘节点。这个覆盖有多夸张？基本上只要是有互联网的城市，就有Cloudflare的节点。从纽约到伦敦，从东京到新加坡，从圣保罗到约翰内斯堡，节点密密麻麻铺了全世界。

而且所有节点是互联互通的，组成了一张全球专用网络。节点之间走的是Cloudflare自己的光纤专线，不走公网，速度快、不堵车。这张网络，就是Cloudflare所有产品的底座。

3.1.4 中国大陆的特殊情况：和京东云合作的便利店

很多人关心：中国大陆有Cloudflare的节点吗？答案是：有，但不是Cloudflare自己运营的，是和京东云合作的。

受国内监管政策要求，境外公司不能直接在国内经营互联网基础设施服务。所以Cloudflare和京东云达成了战略合作，由京东云提供国内的机房、带宽和合规资质，Cloudflare提供技术和全球网络能力。

目前Cloudflare中国网络已经覆盖了国内35个城市，一二线城市基本都有节点。但要注意：

免费版用户用不到国内节点，默认走的是境外节点，国内访问延迟会高一些
企业版用户可以开通中国网络，国内用户会落到国内京东云合作节点，速度和国内CDN差不多
无论哪个版本，只要用国内节点提供服务，域名都必须完成ICP备案

这个点非常重要，后面讲小程序场景的时候还会反复提到。

3.2 静态资源：货架上预包装好的商品

3.2.1 大白话定义

静态资源就是提前做好、内容固定不变的文件。不管谁来买、什么时候来买，拿到的东西都一模一样。就像便利店里的瓶装水、包装饼干、罐装可乐，工厂生产完就封好了，顾客来了直接拿，结账就走，不用等。

它不是“永远不能改”。你可以随时上新版本、换掉旧包装，但在两次更新之间，它的内容是固定的，不会因为顾客不同而变化。比如便利店今天卖的是500ml装的矿泉水，所有人买都是一样的；明天换成550ml新包装，那之后所有人买又都是新的。在换包装的前后，商品本身是固定的。

3.2.2 互联网里的静态资源有哪些？

你每天上网看到的绝大多数“固定内容”，全都是静态资源：

🖼️ 图片类：商品图、头像、图标、banner海报、表情包
📄 文档类：PDF说明书、TXT文本、固定的规则公告
🎵 音视频：背景音乐、短视频素材、课件音频
🌐 网页基础文件：纯HTML页面、CSS样式文件（控制页面长什么样）、固定的JS脚本

举个具体的例子：你打开一个电商小程序，顶部的banner图、底部的导航图标、商品列表里的主图，这些全都是静态资源。因为不管是张三还是李四打开，看到的banner图都是同一张，不会因人而异。

3.2.3 静态资源的核心特点

零计算成本 服务器不用动脑子，不用查数据库，不用跑逻辑。找到文件，直接返回就行，就像便利店店员从货架拿商品，一秒钟的事。
天生适合缓存 因为内容固定，所以可以提前复制很多份，铺到全球每个边缘节点的货架上。用户来了就近拿，不用跑总部仓库。
加载速度极快 缓存后的静态资源，加载速度比从源站拿快60%-80%，源站压力能减少90%以上。一个几兆的图片，从源站加载可能要几秒，从边缘节点缓存加载，可能几百毫秒就出来了。
体积通常比较大 图片、视频这些静态资源，体积往往很大，是最占带宽、最影响加载速度的部分。所以把静态资源加速做好了，网站速度基本就解决了一大半。

3.2.4 常见误区：静态就是不能动？

很多新手以为“静态资源就是永远不能改的”，这是错的。静态只是说“访问的时候不会实时计算生成”，不是说不能更新。你随时可以上传新版本的图片、替换旧的CSS文件，更新之后用户再访问就是新的了。就像便利店可以随时换货架上的商品，换完之后顾客买的就是新的，但在换之前，商品是固定的。

3.3 动态资源：后厨现做的定制餐

3.3.1 大白话定义

动态资源就是收到请求后，服务器临时计算、生成的内容。不同的人、不同的时间、不同的参数，拿到的结果都可能不一样。就像你去餐馆点一份蛋炒饭，要加蛋加火腿、少放盐、多放葱，必须后厨现做，每一份都可能不一样。

再举个更形象的例子：定制生日蛋糕。你要写名字、选口味、加水果插件，每个顾客的要求都不一样，必须收到订单之后现做，不能提前做好放货架上。提前做好的蛋糕，名字都写好了，别人没法用。

3.3.2 互联网里的动态资源有哪些？

所有“因人而异、实时变化、需要算一下”的内容，都是动态资源：

👤 个人数据：“我的”页面的昵称、积分、收藏记录、收货地址，每个人都不同
📦 业务接口：登录验证、下单支付、发布评论、提交表单
📊 实时数据：天气、股票价格、倒计时、在线人数、库存数量
🔍 搜索结果：每个人搜的关键词不一样，返回的结果也不一样
🎨 生成类内容：带昵称的专属海报、验证码图片、AI生成的图片

还是拿电商小程序举例：你点“我的订单”，看到的是你自己的订单记录；别人点，看到的是他的订单。这个订单数据，就是服务器收到你的请求后，去数据库里查你的ID，然后临时生成的。这就是典型的动态资源。

3.3.3 动态资源的核心特点

需要计算 服务器要跑代码、查数据库、做逻辑判断，才能生成结果。就像后厨要洗菜、切菜、炒菜，才能做出一盘菜，需要时间和人力。
千人千面 同一个请求地址，不同的人访问，返回的内容完全不一样。你访问 /my-order 看到的是你的订单，我访问看到的是我的订单。
不好缓存 不能随便缓存起来给下一个人用。如果你查完订单，把结果缓存下来，下一个人访问直接给他看你的订单，那就出大问题了——隐私泄露、数据错乱。动态资源不是完全不能缓存，而是缓存条件很苛刻，不能像静态资源那样简单粗暴地全缓存。
相对更慢 因为要计算、查数据库，还要跑逻辑，通常比静态资源慢很多。而且动态请求必须回源站处理，距离远的话，延迟会更高。

3.3.4 为什么早期CDN管不了动态资源？

早期的CDN，只能处理静态资源。道理很简单：静态的可以提前复制过去放货架上；动态的要现做，便利店没有后厨，做不了。所以那时候的网站，静态资源可以加速，动态接口还是要千里迢迢跑回源站，该慢还是慢。

直到边缘计算出现，便利店有了自己的后厨和店员，简单的动态请求也能在本地处理了。

3.4 CDN内容分发网络：全国连锁便利店配送体系

3.4.1 什么是CDN？

CDN的全称是Content Delivery Network，翻译过来叫「内容分发网络」。名字听起来很玄乎，其实干的事特别简单：把你的静态资源，复制很多份，放到全球各地的边缘节点上，让用户就近获取。

用便利店体系类比：以前只有总部仓库一个发货点，全国人民买水都要从总部寄，慢死了。现在建了全国连锁便利店网络，总部提前把瓶装水运到每个城市的便利店，摆在货架上。用户想买水，下楼去家楼下的便利店买就行，不用等快递。

这就是CDN。分发 = 运过去铺货到各个分店网络 = 全国所有分店组成的一张网

3.4.2 CDN的完整工作流程

我们走一遍完整流程，你就彻底懂了：

源站同步 总部仓库把最新的商品清单，同步给所有便利店。对应：你的源服务器，把静态文件同步给CDN的所有边缘节点。
用户请求 用户打开网站，请求一张图片。对应：顾客想买一瓶可乐。
就近节点响应 请求自动到达离用户最近的边缘节点。对应：顾客走进家楼下的便利店。
缓存命中 节点一看，货架上有这张图片，直接拿给用户。对应：店员从货架拿了一瓶可乐给顾客，交易完成。
缓存未命中（回源） 如果节点货架上没有这个文件怎么办？它会立刻向上级节点或者源站请求，拿到文件之后，先存一份到自己货架上，再返回给用户。下次再有用户要这个文件，就直接有了。对应：顾客要的商品店里没有，店员立刻给总部打电话调货，货到了先放货架上，再给顾客。下次别人再买就有了。

3.4.3 关键指标：缓存命中率

CDN好不好用，最核心的指标就是「缓存命中率」。意思是：一百个请求里，有多少个能直接在边缘节点的货架上拿到，不用回源站。命中率越高，加速效果越好，源站压力越小。

95%命中率：意味着95%的请求都被边缘节点扛了，源站只需要处理5%的请求
50%命中率：一半请求还要回源，加速效果就打了对折

影响命中率的因素很多：缓存时间设置、文件更新频率、用户分布、文件热度等等。好的CDN服务，静态资源命中率通常能做到95%以上。

3.4.4 Cloudflare的CDN强在哪？

和传统CDN相比，Cloudflare的CDN有几个碾压级优势：

节点极多：335个城市全球覆盖，用户总能找到最近的店
免费够用：免费版就有无限流量，小网站完全够用
一键开启：不用复杂配置，改个DNS就自动生效
附带安全：CDN和DDoS防护、WAF绑定在一起，加速的同时还能防攻击

以前CDN是奢侈品，现在免费就能用，这就是Cloudflare给行业带来的改变。

3.5 边缘函数：便利店里的全能店员

3.5.1 从只能卖货到能干活：便利店的进化

早期的边缘节点，就像只有货架、没有店员的自动售货机。它只会干一件事：你要什么，我从货架拿给你。你要加热、要打包、要简单加工，它都做不了，只能回总部处理。

后来大家想：能不能在便利店里安排个店员，让简单的事情直接在店里解决？比如给商品加热、帮你切个水果、简单包装、核对会员身份、回答常见问题…… 这些小事都回总部，太浪费时间了。店员在店里直接处理，又快又省心。

这个“店员”，就是边缘函数。

3.5.2 什么是边缘函数？

边缘函数就是部署在全球边缘节点上的一小段可执行代码。它跑在离用户最近的地方，用户的请求一到，直接就在边缘节点执行代码、处理逻辑，不用再千里迢迢跑到中心服务器。

对应到便利店：

没有边缘函数的节点 = 自动售货机，只能拿现成的
有边缘函数的节点 = 有店员的便利店，能处理各种简单业务

为什么叫“函数”？因为写代码的时候，它就是一个函数（function），接收请求，返回结果。你写好这一段函数代码，部署上去，全球所有边缘节点就都有了这个能力。

3.5.3 边缘函数的核心优势

速度极快 请求不用跑回中心机房，在本地节点就处理完了。本来来回要几百毫秒的延迟，现在可能几十毫秒就搞定了。对于用户来说，就是“点一下立刻有反应”，体验提升非常明显。
不用管服务器 你只需要写代码，剩下的服务器运维、扩容、网络、安全，全由Cloudflare搞定。不用买服务器，不用装系统，不用搭环境，不用管峰值流量。来一个请求就跑一次，来一百万个请求就自动扩容一百万个实例，你完全不用操心。这就是大家常说的「无服务器（Serverless）」——不是没有服务器，是你不用管服务器。
成本极低 按实际请求次数计费，用多少次算多少次。没人访问的时候，不跑代码，就不花钱。而且免费额度很高，个人项目基本用不完。
全球同步部署 你写好代码点一下部署，几十秒内就同步到全球335个城市的所有节点上。全世界的用户，都能在离自己最近的节点执行你的代码。这要是自己去全球部署服务器，简直不敢想象。

3.5.4 Cloudflare Workers：边缘函数的标杆产品

Cloudflare的边缘函数产品叫 Workers，是目前全球最成熟、用户最多的边缘函数产品。它最厉害的地方，是几乎没有“冷启动”问题。

什么是冷启动？就是你的函数很长时间没人调用，系统会把它关掉，释放资源。下次有人调用的时候，要重新启动、加载代码、初始化环境，这个启动过程就叫冷启动。传统的Serverless产品，冷启动时间往往是几百毫秒甚至几秒钟，用户会明显感觉到“卡一下”。

那Workers为什么几乎没有冷启动？因为它用的是浏览器同款的 V8 JavaScript引擎，用的是「Isolate隔离沙箱」技术，而不是传统的容器或虚拟机。

用大白话解释：

传统Serverless冷启动 = 开一台新电脑。要开机、进系统、开软件，很慢，要几百毫秒
Workers冷启动 = 开一个新的浏览器标签页。浏览器已经开着了，新建个标签就行，极快，只要几毫秒甚至不到1毫秒

浏览器里同时开几十个标签页，每个标签页互相不干扰，但共享同一个浏览器进程。Workers也是一样，同一个服务器上跑着成千上万个用户的代码，每个都在独立的沙箱里，安全隔离，但共享同一个V8运行时，启动开销极小。

这个技术选型，是Cloudflare Workers最大的护城河。也是为什么它能做到全球边缘部署、毫秒级启动的根本原因。

3.6 Anycast任播技术：全国统一客服电话

3.6.1 传统IP：一个号码对应一个总店

在讲Anycast之前，我们先说说传统的互联网寻址方式。通常一个IP地址，对应一台服务器（或者一个机房）。就像一个电话号码，对应一个店铺。北京的用户打这个号码，打到北京的店；广州的用户打这个号码，还是打到北京的店。

如果你的服务器在北京，广州用户访问，数据就要从广州跑到北京，绕很远的路。这就是传统的「单播」模式。

3.6.2 Anycast任播：全国分店同一个号码

Anycast（任播）是一种网络技术，简单说就是： 全球所有边缘节点，共用同一个IP地址。

就像连锁便利店搞了一个全国统一客服电话：400-XXXXXXX。不管你在全国哪个地方，拨打这个号码，系统都会自动给你接通离你最近的那家分店。你不用知道分店的具体号码，也不用自己选城市，拨同一个号就行，系统自动安排。

在互联网上也是一样： Cloudflare给你的网站分配一个IP地址，但这个IP不是只在某一个机房，而是全球335个城市的所有节点，都宣告这个IP。当用户发起请求时，互联网上的路由器会自动计算路径，把请求送到离用户物理距离最近、网络最通畅的那个边缘节点。

整个过程完全自动，用户和开发者都感知不到。你不用做任何配置，只要接入Cloudflare，自动就享受Anycast带来的就近访问。

3.6.3 Anycast的额外好处：天然抗攻击

Anycast还有一个巨大的优势：天然抗DDoS。传统单IP模式下，攻击流量全都打向同一个机房，很容易就把带宽打满了。但用了Anycast之后，攻击流量会被自动分散到全球各个节点。就像有人想打电话骚扰你，结果同时打到了全国几百分店，每家店只接到几个电话，根本没影响。

Cloudflare能扛住超大规模DDoS攻击，Anycast技术功不可没。攻击流量被全球几百个节点分摊稀释，再大的攻击，落到单个节点上也没多少了。

3.6.4 为什么不会接错？

很多人会问：全世界这么多节点都用同一个IP，数据包不会送错地方吗？不会。因为互联网的路由器有一个基本原则：选最短路径。路由器之间会互相交换路由信息，知道哪个方向去哪更近。你的请求发出后，每经过一个路由器，它都会选最优的下一跳，最终把你送到最近的节点。

而且如果某个节点故障了，路由器会自动发现这条路不通，立刻切换到第二近的节点。用户完全感知不到故障，服务不会中断。这就是Anycast的高可用性。

3.7 一张表总结所有核心概念

看到这里，你已经掌握了Cloudflare最核心的基础概念。我们用一张表做个总结，方便你回顾：

术语	本质	便利店类比	速度	核心特点
边缘节点	部署在用户附近的服务器	小区楼下的便利店	极近	离用户近，全球分布
静态资源	提前做好的固定文件	货架上的瓶装水	极快	可缓存、内容固定
动态资源	实时计算生成的内容	后厨现做的定制餐	较慢	千人千面、需要计算
CDN	内容分发网络	全国连锁配送体系	快	把静态资源铺到边缘
边缘函数	边缘节点上运行的代码	便利店里的全能店员	很快	就近处理逻辑、无服务器
Anycast	任播网络技术	全国统一客服电话	——	自动就近路由、天然抗攻击

如果你能看懂这张表，说明你已经入门了。接下来我们去看Cloudflare具体有哪些产品，每个产品都是干什么的。

第四部分 Cloudflare全家桶详解：60+产品一次讲明白

很多人第一次进Cloudflare后台，会被密密麻麻的产品列表吓住。什么Workers、Pages、R2、D1、KV、WAF、Zero Trust、Stream、Turnstile……光名字就看得人头大。

别慌。这一章，我会把Cloudflare的主要产品分成四大类，继续用便利店类比，一个个给你讲明白：

加速与缓存类：让你的网站更快
安全防护类：让你的网站更安全
开发者平台类：不用服务器也能做应用
企业网络类：给公司用的组网和安全

每个产品我都会讲清楚：它是什么、通俗类比、能干什么、适合谁用、免费额度有多少。看完这一章，你就能根据自己的需求，精准选择产品，不会再对着后台发呆。

4.1 加速与缓存类产品：让你的网站飞起来

这是Cloudflare最基础、最经典的一类产品。核心目标只有一个：让用户打开你的网站/应用更快。

4.1.1 CDN：基础款连锁配送

这是Cloudflare的立身之本，也是绝大多数用户第一个用到的功能。

通俗类比：全国连锁便利店的基础配送体系，总部把货铺到所有分店货架
核心作用：缓存静态资源到全球边缘节点，用户就近访问，大幅提升加载速度
能缓存什么：图片、视频、CSS、JS、HTML、字体等所有静态文件
免费版支持吗：完全支持，而且不限流量

Cloudflare的CDN有几个非常良心的设计：

默认开启：接入之后自动就有缓存效果，不用复杂配置
智能缓存：系统会自动判断哪些文件该缓存、缓存多久，新手不用管
一键清除缓存：文件更新了，点一下按钮就能让全球节点刷新缓存
缓存规则：高级用户可以自定义规则，精确控制每个文件的缓存策略

对于普通个人网站、博客、小程序静态资源，免费版的CDN完全够用，效果比很多付费CDN还好。

4.1.2 Cache Reserve：超大备用仓库

普通CDN的缓存是“热数据缓存”——经常有人访问的文件留在货架上，长时间没人访问的就会被清掉，腾地方给热门文件。如果你的文件很多、但访问量不高，很多冷门文件会被清掉，用户访问的时候还要回源。

Cache Reserve就是解决这个问题的。

通俗类比：便利店后面的大仓库，货架放不下的货，都放仓库里存着
核心作用：大容量持久化缓存，所有文件都永久存着，不会因为冷门被清掉
适合场景：文件数量极多、长尾访问多、不想频繁回源的站点
收费方式：按存储量和读取次数收费，价格很低

简单说：普通CDN是货架，只放热卖款；Cache Reserve是大仓库，所有货都存着，随时能调。开启之后，回源流量能减少90%以上，源站压力极小。

4.1.3 Argo Smart Routing：智能导航，绕开堵车路段

我们前面说过，互联网的路有时候会堵车。同样两个城市之间，有时候这条线路堵，有时候那条线路堵。普通CDN只会走固定路线，遇上堵车也只能硬等。

Argo Smart Routing就是智能导航系统。

通俗类比：实时路况导航，哪里不堵走哪里
核心作用：实时监测全球网络路况，动态选择最优传输路径，避开拥堵和故障路段
提升效果：平均能让动态请求速度提升30%以上，丢包率大幅下降
收费方式：按流量计费

它的原理是：Cloudflare的全球网络里，所有节点之间有专用光纤专线，还有实时的路况监测系统。用户的请求到了边缘节点之后，不走公网，走Cloudflare自己的私有骨干网，绕开公网的拥堵点，最后从离源站最近的节点出去。相当于普通用户走国道，Argo用户走专属高速，速度自然快很多。

对于动态请求多、跨境访问多的网站，Argo的提升非常明显。

4.1.4 图片优化全家桶：自动给商品减重

图片是网站里体积最大的静态资源，也是拖慢速度的重灾区。很多新手上传图片的时候不压缩，一张图几兆大，加载起来巨慢。 Cloudflare提供了一整套图片自动优化工具，不用你改原图，自动帮你处理：

① Polish：自动压缩图片

自动把图片转换成体积更小的格式（比如WebP、AVIF）
无损压缩，画质几乎看不出区别，体积减少30%-50%
免费版就有基础的压缩功能

② Resize：按需调整图片尺寸

小程序要200x200的缩略图，网页要800宽的主图
不用提前裁好N个版本，传一张原图就行，需要多大尺寸自动生成
按图片处理次数收费

③ Mirage：移动端图片优化

手机网络慢的时候，先加载低分辨率预览图，再慢慢加载高清图
提升移动端的加载体验，减少用户等待

这一套组合拳下来，图片体积能减少一半以上，加载速度大幅提升。对于图片多的电商、博客、小程序，效果立竿见影。

4.1.5 Rocket Loader：让网页JS飞起来

网页里的JS脚本，会阻塞页面渲染。简单说就是：JS没加载完，页面就显示不出来，用户只能看着白屏等。尤其是很多第三方统计、广告、客服的JS，又多又慢，特别拖速度。

Rocket Loader就是解决这个问题的。

通俗类比：先把店面展示给顾客，后台再慢慢装收银系统
核心作用：异步加载所有JavaScript，不阻塞页面显示
效果：首屏加载速度明显提升，白屏时间大幅缩短
免费版支持吗：支持，一键开启

开启之后，网页会先把内容和样式显示出来，JS在后台慢慢加载，用户体验提升非常明显。

4.2 安全防护类产品：给你的网站装铜墙铁壁

安全是Cloudflare的另一块核心业务，甚至比CDN更早起步。从最早的反垃圾邮件项目，到现在全球领先的DDoS防护能力，安全一直是它的看家本领。

4.2.1 DDoS防护：挡住上门闹事的混混

这是Cloudflare最出名的能力，也是免费版最良心的功能之一。

通俗类比：专业保安团队，有人来闹事直接拦在门外，不会冲进店里
什么是DDoS：黑客控制大量僵尸设备，同时给你发海量请求，把你的带宽和服务器占满，正常用户进不来
Cloudflare怎么防：
1. Anycast分散攻击流量，全球几百个节点一起扛
2. 边缘节点实时清洗，恶意流量直接丢掉，正常流量放进去
3. 全球500Tbps的总防护能力，再大的攻击也扛得住
免费版有吗：有，而且是无上限防护，不管多大攻击都免费帮你挡

很多小网站以前动不动就被打挂，接入Cloudflare之后，再也不用担心DDoS了。这也是Cloudflare被称为“赛博活佛”的重要原因——别人几十万的防护服务，它免费给你用。

4.2.2 WAF Web应用防火墙：智能安检门

DDoS防护是防“堵门的”，WAF是防“带危险品进门的”。

通俗类比：机场的安检门，每个乘客都要过一遍，带刀、带汽油的直接拦下来
核心作用：检查每一个HTTP请求，识别并拦截恶意攻击，比如SQL注入、XSS跨站脚本、木马上传、漏洞扫描等等
免费版有吗：有基础的WAF规则，能防绝大多数常见攻击
付费版升级：更多内置规则、自定义规则、高级威胁情报

举几个WAF能防的攻击例子：

坏人想在你的登录框里写恶意代码，偷数据库数据 → WAF直接拦下
坏人想上传木马文件控制你的服务器 → WAF识别出来直接拒绝
坏人用扫描器扫你的网站漏洞 → WAF直接拉黑他的IP

对于普通网站，开启免费版WAF，就能挡住99%的常见Web攻击。

4.2.3 Bot Management机器人管理：分辨真人还是黄牛

互联网上的流量，有一半以上是机器人。机器人有好有坏：

✅ 好机器人：搜索引擎爬虫、监控脚本、合法API调用
❌ 坏机器人：爬虫盗内容、黄牛抢票、暴力破解密码、刷流量、垃圾评论

Bot Management就是用来区分好坏机器人的。

通俗类比：检票口的工作人员，一眼就能认出谁是真人顾客，谁是黄牛票贩子
核心作用：通过行为分析、指纹识别、人机验证等方式，识别并拦截恶意机器人
适合场景：电商、票务、内容站点、有会员系统的网站
免费版有吗：免费版只有基础的机器人管理，付费版功能更强

很多网站被爬虫爬数据、被暴力破解账号，开启Bot Management之后，情况会好很多。

4.2.4 Turnstile：无感验证码，不用再点图片

说起验证码，大家都很烦。 “请找出所有包含红绿灯的图片”、“拖动滑块完成拼图”，又麻烦又费时间。但不用验证码，又挡不住机器人。

Turnstile是Cloudflare推出的无感人机验证产品。

通俗类比：智能安检，你正常走过去就行，系统偷偷扫描判断你是不是好人，不用你停下来掏证件
核心作用：不用用户做任何操作，后台通过浏览器行为、环境特征，自动判断是真人还是机器人
优势：
1. 用户完全无感，体验极好
2. 比传统验证码更安全，更难被破解
3. 完全免费，接入简单
能用在小程序里吗：可以，有对应的SDK

现在越来越多的网站和小程序，都开始用Turnstile代替传统验证码。用户不用再点图片，体验提升一大截，安全性还更高。

4.2.5 SSL/TLS证书：给包裹上锁，半路没人能拆开看

现在的网站，基本都要用HTTPS。 HTTPS的作用，就是给传输的数据加密，防止数据在半路被人偷看、篡改。而加密需要SSL证书。

以前申请SSL证书很麻烦，还要花钱买，一年几百到几千不等。 Cloudflare直接免费送，而且是一键开启，自动续期。

通俗类比：给所有快递都加上封条和密码锁，只有收件人能打开，半路没人能拆
核心作用：免费提供HTTPS证书，自动签发、自动续期，全站加密
免费版有吗：有，无限域名，永久免费
支持的证书：通用DV证书，个人和小企业完全够用

很多人用Cloudflare，就是冲着免费SSL证书来的。不用自己申请、不用自己配置、不用操心过期，一键开启，非常省心。

4.2.6 DNS解析服务：互联网的地址本

DNS（域名系统）是互联网的地址本。你输入域名，DNS负责把它翻译成IP地址，你的电脑才能找到服务器。

Cloudflare的公共DNS 1.1.1.1，是全球最快的公共DNS服务。同时它也提供权威DNS解析服务，就是把你的域名托管在Cloudflare上。

通俗类比：全国最准、最快的地址查询台
核心优势：
1. 速度快：全球节点分布，解析延迟极低
2. 安全：防DNS劫持、防DNS污染
3. 稳定：几乎100%可用性
4. 免费：免费版就支持无限域名

绝大多数人用Cloudflare的第一步，就是把域名的DNS解析迁过来。这是所有其他服务的基础。

4.3 开发者平台类产品：不用服务器也能做应用

这是近几年Cloudflare发展最快的板块，也是最适合个人开发者、小团队的部分。以前你想做个网站、做个API，必须买服务器、搭环境、运维。现在你只用写代码，剩下的全交给Cloudflare。

这部分产品最多，也是新手最容易搞混的，我们一个个讲。

4.3.1 Cloudflare Workers：边缘店员的核心

Workers是整个开发者平台的核心，所有其他产品都是围绕它展开的。

通俗类比：便利店里的全能店员，能处理各种业务逻辑
本质：运行在全球边缘节点上的Serverless函数服务
支持语言：JavaScript、TypeScript、Python、Rust、C/C++等
技术原理：基于V8引擎的Isolate沙箱，冷启动不到5毫秒
免费额度：每天10万次请求，每天10万毫秒CPU时间，最多100个脚本

Workers能做什么？

几乎所有后端能做的轻量事情，它都能做：

写API接口：小程序后端、网站后端、移动端接口
接口代理：转发请求、中转第三方接口、加速境外接口
数据处理：图片处理、格式转换、数据清洗
定时任务：每天自动爬数据、自动签到、自动备份
权限校验：在边缘层做登录验证、访问控制
网页渲染：生成HTML页面、做服务端渲染

举几个真实的用法例子：

写一个天气查询API，用户请求就近返回
做一个OpenAI接口代理，国内也能顺畅调用
写一个图片水印接口，上传图片自动加水印
做一个短链接服务，跳转统计都在边缘完成

对于轻量业务，Workers完全可以代替传统后端服务器。不用运维、不用扩容、全球加速，成本几乎为零。

Workers的局限

当然它也不是万能的：

CPU时间限制：免费版单请求最多10ms CPU时间，复杂计算扛不住
内存限制：每个Worker最多128MB内存，大文件处理不行
无状态：默认每次请求都是独立的，不能直接存状态
数据库能力有限：边缘数据库性能不如传统中心化数据库

简单说：它适合轻、快、简单的逻辑，不适合重、复杂、强一致的核心业务。

4.3.2 Workers KV：便利店的小储物柜

KV的全称是Key-Value，键值存储。简单说，就是一个巨大的字典：你给一个名字（Key），就能存对应的值（Value）。

通俗类比：便利店里的带锁储物柜，给你一把钥匙对应一个柜子
本质：分布式边缘键值存储数据库
适合存什么：配置信息、登录态Token、用户偏好、计数器、小文本数据
免费额度：1GB存储空间，每天10万次读取，每天1000次写入

KV的特点

读极快：数据缓存到边缘节点，读取速度非常快，几毫秒就能返回
写稍慢：写入需要同步到全球所有节点，有几秒到几十秒的延迟
结构简单：只有键值对，不能复杂查询，不能建表
容量大：单个值最大25MB，能存不小的文件

适合场景

存用户的登录Token：验证的时候快速读取
存网站的配置开关：比如功能开关、文案配置
存简单的计数：比如页面访问量、下载次数
存静态小文件：比如小图标、配置文件

不适合场景

频繁写入的数据：写入慢，而且有额度限制
需要复杂查询的数据：只能按键查，不能按条件搜
强一致性要求高的数据：全球同步有延迟，可能读到旧数据

一句话总结：KV是读快写慢的简单存储，适合存读多写少、不那么重要的小数据。

4.3.3 D1数据库：便利店的小型进销存系统

如果说KV是储物柜，那D1就是正经的账本。 D1是Cloudflare推出的边缘SQL数据库，支持标准的SQL语法，基于SQLite构建。

通俗类比：便利店里的进销存账本，有表格、能查询、能统计
本质：分布式边缘关系型数据库
语法：标准SQL，和MySQL、SQLite基本通用
免费额度：每个账号5个数据库，总容量5GB，每天10万次读取

D1的特点

边缘部署：数据库就近部署，查询延迟低
标准SQL：学习成本低，现有代码很容易迁移
轻量易用：不用建实例、不用配参数，创建就能用
事务支持：支持数据库事务，保证数据一致性

适合场景

小程序后端：用户表、收藏表、订单表，轻量业务完全够用
小型网站后端：博客评论、留言板、内容管理
工具类应用：待办清单、记账、数据记录
原型开发：快速做产品原型，不用搭数据库

不适合场景

超大流量：QPS很高的核心业务，性能不如专业数据库
复杂关联查询：多表联查、复杂统计，性能一般
海量数据：单库容量有限，不适合存几百万条大数据

对于个人开发者、小型项目，D1绝对是神器。不用买数据库服务器，不用运维，搭配Workers，一套完整的后端就有了。

4.3.4 R2对象存储：便利店的大仓库

R2是Cloudflare的对象存储产品，对标亚马逊的S3。什么是对象存储？简单说就是专门存文件的大仓库，图片、视频、压缩包、备份文件……什么文件都能存。

通俗类比：便利店后面的超大仓库，专门放各种大件商品和货物
本质：分布式对象存储服务
兼容性：兼容S3 API，现有S3的代码和工具基本都能直接用
免费额度：10GB存储空间，每月100万次写入操作，1000万次读取操作

R2最大的杀招：出站流量免费

这是R2和其他对象存储最大的区别，也是最良心的地方。传统对象存储，存储费不贵，但出站流量费（下载流量）巨贵。比如AWS S3，下载1TB流量要几百块钱。如果你的图片很多、访问量很大，流量费账单会吓死人。

而R2的出站流量，完全免费。不管你下载多少TB，都不花钱。只有存储和操作次数收费，免费额度还很高。这对于图床、视频站、下载站来说，简直是降维打击。

适合场景

小程序图床：商品图、表情包、素材图，流量多大都不怕
文件下载站：安装包、资料、文档，不用担心流量费
数据备份：网站备份、数据库备份，便宜又安全
视频托管：短视频、教学视频，配合Stream用

注意点

R2默认没有CDN缓存，一般会搭配CDN一起用，速度更快
国内访问R2默认走境外节点，速度一般，需要备案域名优化
小文件很多的话，操作次数费用可能会超过存储费

总的来说，R2是目前性价比最高的对象存储之一，尤其是流量大的场景，能省一大笔钱。

4.3.5 Pages：静态网站托管

Pages是Cloudflare的静态网站托管产品。什么是静态网站？就是全部由静态资源组成的网站，没有后端、没有数据库，页面内容都是提前生成好的。比如个人博客、文档站、产品官网、活动落地页。

通俗类比：专卖预包装商品的便利店，没有后厨，全是现成商品
本质：静态网站托管+全球CDN加速
支持框架：React、Vue、Next.js、Hexo、Hugo、Jekyll等几乎所有主流静态框架
免费额度：无限站点数量、无限带宽、每月500次构建次数

Pages怎么用？

非常简单，新手也能上手：

把你的网站代码放到Github仓库里
在Pages后台绑定这个仓库
选择构建命令和输出目录
点击创建，自动开始构建部署

以后你每次更新代码，提交到Github，Pages都会自动重新构建、自动部署。还会自动给每个提交生成预览链接，方便测试。

Pages Functions：店里加个小服务台

Pages不仅能放静态网站，还自带Functions功能——就是简化版的Workers。你可以在Pages项目里写接口函数，实现简单的后端逻辑。比如表单提交、留言板、简单查询，都可以直接在Pages里搞定，不用单独开Worker。

这样一来，静态页面+简单后端，一个Pages就全搞定了。对于个人博客、小型官网，完全够用。

4.3.6 Workers AI：边缘端的AI推理

近几年AI大火，Cloudflare也把AI能力搬到了边缘节点上。 Workers AI可以让你在边缘节点上运行AI模型，直接在离用户最近的地方做推理。

通俗类比：便利店里放了一台智能自助机，顾客有问题当场就能AI解答，不用等总部客服
本质：边缘AI推理服务，在边缘节点跑大模型
支持模型：文本生成、图片生成、语音识别、翻译、嵌入模型等几十种
计费方式：按推理时长计费，价格很低

Workers AI的优势

延迟低：模型在边缘跑，不用把数据传到千里之外的AI机房，响应更快
隐私好：数据不用传到中心机房，在本地节点就处理了，更安全
弹性扩容：自动扩缩容，不用管GPU资源
开发简单：几行代码就能调用AI能力

适合场景

小程序里的AI功能：AI写文案、AI修图、AI翻译
实时AI交互：智能客服、实时翻译
图片处理：AI抠图、AI增强、AI生成海报

目前Workers AI的模型还不算特别大，适合轻量的AI场景。但它的优势是离用户近、延迟低，对于实时性要求高的场景非常合适。

4.3.7 Durable Object：有状态的边缘对象

Workers默认是无状态的——每次请求都是独立的，两次请求之间不共享内存。这就导致有些场景不好做，比如实时聊天、游戏房间、计数器，需要持续保持状态。

Durable Object（持久对象）就是解决这个问题的。

通俗类比：专属的店员，专门服务某一个场景，能记住之前的对话和状态
本质：有状态的边缘计算单元，能持久化保存状态
特点：全局唯一、长生命周期、能保持内存状态、支持事务

适合场景

实时聊天房间：每个房间一个Durable Object，保存房间状态和消息
多人协作：在线文档、协同白板，实时同步状态
在线游戏：游戏房间、实时对战，保持游戏状态
精确计数器：高并发下精确计数，不会有误差

这个功能比较进阶，普通开发者用得不多。但做实时应用、多人协作项目的时候，它是神器。

4.3.8 Stream：视频托管和直播

Stream是Cloudflare的视频点播和直播服务。

通俗类比：便利店的视频放映厅，上传片源之后，自动转码，全球播放
本质：一站式视频托管、转码、分发服务
功能：视频上传、自动转码、全球CDN分发、播放器、直播推流
计费：按存储分钟数和观看分钟数计费，没有额外流量费

优势

简单：上传视频就完事了，不用自己转码、配CDN
便宜：按分钟计费，成本比自己搭低很多
全球加速：300多个节点分发，全球观看都流畅
无流量费：只算观看时长，不算流量，不用担心爆账单

适合场景

课程视频、教学视频托管
小程序里的短视频播放
企业内训视频、产品演示视频
低延迟直播

对于视频量不大的中小项目，Stream非常省心。

4.3.9 其他开发者工具

除了这些核心产品，还有很多实用的小工具：

Queues：消息队列，异步处理任务，比如发邮件、处理图片
Cron Triggers：定时触发器，定时跑Worker，比如每天凌晨备份数据
Browser Rendering：边缘浏览器渲染，爬取动态网页、生成截图
Hyperdrive：数据库加速代理，加速连接传统中心化数据库
Vectorize：向量数据库，做RAG、AI知识库用

这些产品组合起来，已经能覆盖绝大多数Web应用的开发需求。很多小团队和个人开发者，已经完全不用传统云服务器了，全套都跑在Cloudflare上。

4.4 企业网络与零信任类产品

这部分主要是给企业用的，个人用户接触得少，我们简单了解一下就行。

4.4.1 Zero Trust 零信任访问

传统的企业安全思路是：公司内网是安全的，外面是危险的。只要连进公司内网，就能访问内部系统。但现在远程办公越来越多，员工在外面、在家里，也需要访问公司系统。 VPN又慢又不安全，还容易被攻破。

零信任的理念是：永不信任，始终验证。不管你在公司内还是公司外，每次访问系统，都要验证身份和设备状态。

通俗类比：公司大楼的门禁系统，每个楼层、每个办公室都要刷卡，不是进了大门就能随便逛
核心产品：Cloudflare Access
作用：保护企业内部应用，不用VPN，通过浏览器就能安全访问，支持多因素认证

4.4.2 Cloudflare One 企业网络

这是面向企业的一站式网络解决方案。把企业的各个办公室、数据中心、云服务器、员工设备，全部通过Cloudflare的全球网络连起来，组成一个安全的企业内网。不用自己拉专线，不用买昂贵的网络设备，全部云端搞定。

4.4.3 Magic Transit 全网络防护

把企业的整个IP网络接入Cloudflare，所有流量先经过Cloudflare清洗再进来。不仅防护网站，还能防护所有TCP/UDP应用，比如游戏服务器、邮件服务器、数据库等。相当于给企业的整个网络入口，加了一层巨型DDoS防护盾。

4.4.4 WARP 个人网络加速

这是给普通用户用的免费工具，手机和电脑都能装。相当于给你的个人网络加了一层加密和优化。

公共WiFi下保护隐私，防止被窃听
优化网络路由，让访问更快更稳定
基础版完全免费，高级版付费

很多人用它来优化跨境访问的速度，效果还不错。

4.5 一句话总结每个产品

最后，我们用一句话总结每个核心产品，方便你快速查阅：

产品	一句话解释	适合谁
CDN	静态资源全球缓存加速	所有网站、小程序
WAF	Web应用防火墙，挡黑客攻击	所有网站、API
DDoS防护	挡流量攻击，防止网站被打挂	所有站点
SSL证书	免费HTTPS加密	所有站点
DNS	域名解析服务	所有域名
Workers	边缘函数，在节点上跑代码	开发者、做API、做后端
KV	边缘键值存储，读快写慢	存配置、Token、小数据
D1	边缘SQL数据库	小程序后端、小型项目
R2	对象存储，出站流量免费	图床、文件、视频
Pages	静态网站托管	博客、官网、文档站
Workers AI	边缘AI推理	轻量AI功能、实时AI
Stream	视频托管直播	视频站点、课程
Turnstile	无感人机验证	登录、注册、表单页
Zero Trust	企业零信任安全	企业、远程办公
WARP	个人网络加速保护	普通用户

第五部分全程拆解：一次小程序访问到底经历了什么？

讲了这么多概念和产品，你可能还是有点抽象。这一章，我们拿一个真实场景，从头到尾拆解一次完整的访问流程。你跟着走一遍，所有知识点就串起来了。

5.1 场景设定

我们用你最关心的微信小程序场景：

你做了一个壁纸小程序
后端用 Cloudflare Workers + D1 + R2 搭建
绑定了自己的备案域名 api.bizhi.com
用户在广州，用微信打开小程序，点击「我的收藏」

我们来一步步看，从用户点击，到页面显示收藏列表，中间都发生了什么。

5.2 第一步：域名解析，找到便利店地址

用户点击「我的收藏」按钮，小程序要发起网络请求。第一步，得先知道 api.bizhi.com 这个域名对应的IP地址是什么。

小程序先查手机本地的DNS缓存：有没有存过这个域名的地址？
- 如果有，直接用；如果没有，去问运营商DNS
运营商DNS发现，这个域名的NS服务器是Cloudflare的
运营商DNS向Cloudflare的DNS服务器查询IP
Cloudflare DNS返回一个Anycast IP地址

这个过程，就像顾客想找便利店地址，先查手机地图，地图告诉他：“全国统一客服电话是400-XXXXXXX”。

这里有个关键点：返回的不是某一个城市的IP，而是Cloudflare全球共用的Anycast IP。用户不用管具体哪个节点，后面网络会自动路由。

5.3 第二步：Anycast路由，接到最近的广州店

拿到IP地址之后，小程序发起HTTP请求。数据包从用户的手机发出，经过运营商网络，开始往目标IP走。

互联网上的路由器每经过一跳，都会算一次最优路径。因为是Anycast IP，广州的路由器发现，广州本地就有Cloudflare的节点，走这条路最近。于是数据包直接被送到了广州的边缘节点。

整个过程完全自动，不用用户选，也不用开发者配置。如果广州的节点故障了，路由器会自动把流量导到深圳或者长沙的节点，用户完全感知不到。

这就像你打全国统一客服电话，系统自动给你接广州本地的分店，不用你自己选城市。

5.4 第三步：安全检查，先过安检门

请求到达广州边缘节点之后，不是直接就去跑代码。先过三道安全检查：

第一道：DDoS清洗

系统先判断这个请求是不是正常的。是不是恶意攻击流量？是不是僵尸网络发来的？如果是攻击流量，直接丢掉，根本不会进入下一步。正常流量，放行。

第二道：WAF防火墙

然后检查请求内容。 URL里有没有恶意代码？请求体里有没有SQL注入？Header里有没有异常？常见的攻击特征，直接拦截，返回403错误。正常请求，继续放行。

第三道：规则引擎

如果你设置了自定义规则，比如“某个IP访问太频繁就拉黑”、“某个路径需要校验Token”，在这里执行。符合拦截规则的，直接拦下。

三道检查都过了，请求才真正进入业务逻辑处理环节。这三道门，把绝大多数恶意请求都挡在了外面，你的后端代码根本感知不到攻击的存在。

5.5 第四步：静态资源直接拿，动态找店员

如果请求的是静态资源，比如壁纸图片：

节点先查本地缓存：货架上有没有这张图？
有：直接返回图片，请求结束，全程几毫秒
没有：去R2存储里取，缓存一份到本地，再返回给用户

但我们这个场景是请求收藏列表接口，属于动态资源。所以它会被分发到对应的Worker函数去处理。就像顾客要办会员业务，不是去货架拿商品，而是找店员处理。

5.6 第五步：边缘函数执行，查数据库

请求到达Worker运行时。系统先看：这个Worker的Isolate沙箱是不是已经启动了？

如果是热的（刚有人用过）：直接恢复上下文，开始执行代码
如果是冷的（第一次或者很久没人用）：创建一个新的Isolate，加载代码

因为Isolate启动极快，只有几毫秒，用户根本感觉不到冷启动。这就是Workers比传统Serverless快的地方。

代码开始执行，分几步：

校验登录态：从请求Header里取出用户Token，去KV里查这个Token对不对、有没有过期。
- Token无效：直接返回“请先登录”，请求结束
- Token有效：拿到用户ID，继续下一步
查询数据库：用用户ID，去D1数据库里查收藏表，找出这个用户收藏的所有壁纸ID。
组装数据：把查询结果整理成小程序需要的JSON格式，加上状态码、提示信息。
返回响应：把JSON数据返回出去。

整个逻辑都在广州的边缘节点本地执行，数据库也在就近的边缘节点，不用跑回遥远的中心机房。所以整个过程非常快，可能几十毫秒就处理完了。

5.7 第六步：结果返回给小程序

处理完的响应数据，沿着原路返回给用户的手机。小程序收到JSON数据，解析之后，把收藏列表渲染到页面上。

用户从点击按钮，到看到列表，整个过程可能不到100毫秒。用户的感受就是：点一下立刻就出来了，非常流畅。

5.8 整个流程的时间账

我们来算一笔时间账，看看为什么边缘架构这么快：

环节	传统中心化服务器（北京）	Cloudflare边缘节点（广州）
网络传输往返	约60ms（广州→北京往返）	约10ms（广州本地往返）
安全检查	源站自己处理，约10ms	边缘节点处理，约1ms
逻辑执行+查库	约50ms	约30ms
总耗时	约120ms	约41ms

速度提升了将近3倍。如果服务器在境外，差距会更大，传统方式可能要几百毫秒，边缘方式还是几十毫秒。

这就是边缘计算的价值：把计算搬到离用户最近的地方，大幅减少网络传输时间。

而且这还只是单个请求的提升。如果一个页面有十几个请求，加起来提升就非常明显了。

第六部分实战应用场景：普通人能用Cloudflare干什么？

讲了这么多理论和产品，终于到了最实用的部分。普通人、个人开发者、小程序创业者，到底能用Cloudflare做什么？每个场景怎么搭配产品？有哪些注意事项？

这一章，我们挑7个最常用的场景，详细拆解。重点讲你最关心的微信小程序场景，会讲得特别细。

6.1 场景一：微信小程序后端（重点详解）

这是你最关心的问题，我们放在第一个讲。先把结论说清楚，再慢慢展开。

6.1.1 能不能部署小程序前端？为什么不能？

绝对不能。 很多新手以为：Cloudflare能托管网页，那能不能托管小程序？完全不是一回事。

微信小程序的前端代码（wxml、wxss、js、json）有严格的平台规则：

必须通过微信开发者工具打包上传，提交到微信官方服务器
由微信客户端负责分发、运行、渲染
审核、发布、版本管理，全流程都在微信公众平台内完成
不能托管在任何第三方服务器上

简单说：小程序前端没有“部署到自己服务器”这一说，天然就是微信托管的。你想自己托管也托管不了，微信根本不允许。

所以记住：Cloudflare不能部署小程序前端，只能部署小程序的后端和静态资源。

6.1.2 小程序能用Cloudflare做什么？

虽然前端不能部署，但后端和周边服务，Cloudflare能帮上大忙。主要有四个用处：

① 后端API接口

这是最核心的用法。用 Workers + D1 + KV 搭后端，写接口给小程序调用。比如登录、收藏、评论、列表查询、数据提交…… 轻量小程序的后端，完全可以用Cloudflare搞定，不用买服务器。

② 静态资源托管

小程序里的图片、音频、视频、PDF等素材，都可以存在R2上，走CDN加速。比存在腾讯云COS上，流量费便宜很多，甚至免费额度就够用。

③ 接口代理加速

如果你的后端在境外，或者要调用境外的第三方接口（比如AI接口），小程序直接访问会很慢甚至超时。可以用Workers做一层代理，小程序先请求国内边缘节点，由Worker去调用境外接口，再把结果返回来。利用Cloudflare的专线网络，速度会比直接连快很多。

④ 安全防护

给你的后端接口加一层WAF和DDoS防护，防止被攻击、被恶意刷接口。免费版就够用，不用额外花钱。

6.1.3 最关键的前提：ICP备案域名

这是90%的新手都会踩的坑，必须放在最前面说。

微信小程序有硬性规定：所有 request、uploadFile、downloadFile、socket 的合法域名，必须是完成ICP备案的域名。没有备案的域名，根本没法在小程序后台配置，真机调用会直接报错，连调试都不行。

而Cloudflare默认给你的域名：

*.workers.dev
*.pages.dev
*.r2.dev

全都是境外域名，没有ICP备案，绝对不能直接填到小程序后台。很多新手写完Worker，直接把workers.dev的地址填进去，发现小程序里调用失败，就是这个原因。

正确做法

买一个域名：在国内注册商（比如阿里云、腾讯云）买一个域名
做ICP备案：按照注册商的指引提交备案，一般1-2周能下来
DNS托管到Cloudflare：备案通过后，把域名的DNS解析改成Cloudflare的
绑定自定义域名：在Worker/Pages/R2后台，绑定你的备案域名
配置小程序合法域名：把这个备案域名填到小程序后台

只有走完这五步，你的Cloudflare服务才能在小程序里正常使用。

很多人问：域名备案了，但服务跑在境外节点上，合规吗？严格来说，不完全符合“互联网信息服务需境内服务器”的监管要求。但个人学习、非盈利、低流量的项目，一般没人管；商业运营、涉及用户数据的项目，还是建议用国内云服务更稳妥。

6.1.4 技术方案选型：Workers + D1 + R2

做小程序后端，最经典的搭配就是这三件套：

Workers：跑业务逻辑，处理接口请求
D1：存结构化数据，比如用户表、收藏表、分类表
R2：存图片、音频等静态文件资源

这套组合有几个巨大优势：

成本极低：免费额度就能支撑几千日活的小程序，超出了也很便宜
全球加速：不管用户在哪，都能就近访问
不用运维：不用管服务器、数据库扩容、安全补丁
上手简单：会写JS就能做，学习成本很低

什么小程序适合用这套方案？

✅ 推荐：工具类、内容展示类、轻量交互类

壁纸、表情包、头像小程序
工具类：计算器、查询、记录类
内容类：美文、语录、科普
轻量社区：简单的发帖、评论

❌ 不推荐：重业务、高并发、强一致性、涉及支付核心

电商、外卖、出行类核心业务
高并发的秒杀、抢票
涉及大量用户隐私数据
微信支付、退款等核心金融逻辑

6.1.5 完整例子：壁纸小程序的收藏功能

光说不练假把式。我们拿「收藏壁纸」这个最常见的功能，走一遍完整流程，你就知道怎么落地了。

需求分析

用户在壁纸详情页，点击收藏按钮，把这张壁纸加入自己的收藏列表；在「我的」页面，能看到自己收藏的所有壁纸。

数据库设计

我们在D1里建两张表：

用户表 users

字段名	类型	说明
id	integer	用户ID，主键，自增
openid	text	微信openid，唯一
nickname	text	昵称
avatar	text	头像地址
created_at	integer	创建时间

收藏表 favorites

字段名	类型	说明
id	integer	收藏ID，主键，自增
user_id	integer	用户ID，外键
wallpaper_id	text	壁纸ID
wallpaper_url	text	壁纸图片地址
created_at	integer	创建时间

建表SQL：

CREATE TABLE users (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  openid TEXT UNIQUE NOT NULL,
  nickname TEXT,
  avatar TEXT,
  created_at INTEGER NOT NULL
);

CREATE TABLE favorites (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  user_id INTEGER NOT NULL,
  wallpaper_id TEXT NOT NULL,
  wallpaper_url TEXT NOT NULL,
  created_at INTEGER NOT NULL,
  UNIQUE(user_id, wallpaper_id)
);

接口设计

我们需要三个接口：

POST /api/favorite/add：添加收藏
POST /api/favorite/remove：取消收藏
GET /api/favorite/list：获取收藏列表

每个接口都要先校验用户登录态。

Worker代码逻辑（伪代码讲解）

我们用JS来写，非常简单：

// 1. 监听请求
export default {
  async fetch(request, env, ctx) {
    const url = new URL(request.url);
    const path = url.pathname;
    
    // 统一处理OPTIONS预检请求
    if (request.method === 'OPTIONS') {
      return new Response(null, {
        headers: corsHeaders
      });
    }

    // 路由分发
    if (path === '/api/favorite/add' && request.method === 'POST') {
      return addFavorite(request, env);
    } else if (path === '/api/favorite/remove' && request.method === 'POST') {
      return removeFavorite(request, env);
    } else if (path === '/api/favorite/list' && request.method === 'GET') {
      return getFavoriteList(request, env);
    }

    return new Response('Not Found', { status: 404 });
  }
}

// 2. 添加收藏接口
async function addFavorite(request, env) {
  // 第一步：校验Token，获取用户ID
  const userId = await verifyToken(request, env);
  if (!userId) {
    return json({ code: 401, msg: '请先登录' });
  }

  // 第二步：读取请求参数
  const { wallpaperId, wallpaperUrl } = await request.json();

  // 第三步：插入数据库
  const stmt = env.DB.prepare(
    'INSERT OR IGNORE INTO favorites (user_id, wallpaper_id, wallpaper_url, created_at) VALUES (?, ?, ?, ?)'
  );
  await stmt.bind(userId, wallpaperId, wallpaperUrl, Date.now()).run();

  return json({ code: 0, msg: '收藏成功' });
}

// 3. 取消收藏接口
async function removeFavorite(request, env) {
  const userId = await verifyToken(request, env);
  if (!userId) {
    return json({ code: 401, msg: '请先登录' });
  }

  const { wallpaperId } = await request.json();
  
  const stmt = env.DB.prepare(
    'DELETE FROM favorites WHERE user_id = ? AND wallpaper_id = ?'
  );
  await stmt.bind(userId, wallpaperId).run();

  return json({ code: 0, msg: '取消成功' });
}

// 4. 获取收藏列表接口
async function getFavoriteList(request, env) {
  const userId = await verifyToken(request, env);
  if (!userId) {
    return json({ code: 401, msg: '请先登录' });
  }

  const stmt = env.DB.prepare(
    'SELECT * FROM favorites WHERE user_id = ? ORDER BY created_at DESC LIMIT 20'
  );
  const { results } = await stmt.bind(userId).all();

  return json({ code: 0, data: results });
}

代码非常简单，就是接收请求、校验身份、操作数据库、返回结果。和你写普通的Node.js后端几乎一模一样，只是运行环境不一样。

小程序端调用代码

小程序里调用，和调用普通接口没有任何区别：

// 添加收藏
wx.request({
  url: 'https://api.yourdomain.com/api/favorite/add',
  method: 'POST',
  header: {
    'Authorization': wx.getStorageSync('token')
  },
  data: {
    wallpaperId: '12345',
    wallpaperUrl: 'https://cdn.yourdomain.com/wallpaper/12345.jpg'
  },
  success(res) {
    if (res.data.code === 0) {
      wx.showToast({ title: '收藏成功' });
    }
  }
})

// 获取收藏列表
wx.request({
  url: 'https://api.yourdomain.com/api/favorite/list',
  method: 'GET',
  header: {
    'Authorization': wx.getStorageSync('token')
  },
  success(res) {
    if (res.data.code === 0) {
      this.setData({
        list: res.data.data
      });
    }
  }
})

你看，小程序端完全感知不到后端是跑在Cloudflare上的，和调用腾讯云、阿里云的接口一模一样。

部署步骤

在Cloudflare后台创建一个D1数据库，执行建表SQL
写好Worker代码，配置好D1数据库绑定
部署Worker，绑定你的备案自定义域名
在小程序后台配置request合法域名
真机测试，确认能正常调用

整个流程，熟练的话半小时就能搞定。不用买服务器，不用装数据库，不用配环境，全程网页后台操作。

6.1.6 优缺点总结

优点

成本极低：免费版每天10万次请求，个人小程序基本用不完
上手简单：会JS就能写后端，不用懂运维
自带CDN和安全：不用额外配置加速和防护
弹性扩容：用户突然暴涨也不怕，自动扛住

缺点

备案门槛：必须有备案域名，新手可能会卡在这里
国内速度一般：免费版走境外节点，国内延迟几十到一百多毫秒，工具类够用，对延迟要求高的不行
功能有限：复杂业务、长耗时计算、大事务处理不了
合规风险：商业项目长期用，可能有合规隐患

给你的建议

个人学习、练手、做工具类小程序：非常推荐，成本低、上手快
正式商业运营、用户量大、涉及支付：不推荐，老老实实上国内云

6.2 场景二：搭建个人博客/网站

这是Cloudflare最经典的个人用法之一。不用买服务器、不用买虚拟主机，几十分钟就能搭一个速度飞快的个人博客。

6.2.1 技术方案

Hexo/Hugo + Cloudflare Pages + 自定义域名

Hexo/Hugo：静态博客生成器，把Markdown文章转成静态HTML页面
Pages：托管生成好的静态网站，全球CDN加速
自定义域名：绑定你自己的域名，开启免费HTTPS

6.2.2 优势

完全免费：Pages免费版无限带宽、无限站点，一分钱不花
速度极快：全球边缘节点缓存，国内外访问都很快
部署简单：写好文章提交到Github，自动构建部署
安全省心：不用管服务器漏洞、不用备份、不怕攻击
支持自定义：主题、插件随便装，和自己搭的没区别

6.2.3 适合谁

技术博主、写作者
产品官网、个人作品集
文档站、知识库
活动落地页、单页网站

对于不需要后端的纯展示站点，Pages绝对是第一选择。

6.3 场景三：免费图床/文件托管

做自媒体、做小程序、写博客，都需要图床。传统图床要么限速、要么有广告、要么容易跑路、要么流量费贵。用Cloudflare R2自己搭一个，完全可控，还不用担心流量费。

6.3.1 技术方案

Cloudflare R2 + 自定义域名 + CDN缓存

R2：存图片文件，出站流量免费
CDN：缓存图片，加快访问速度，减少R2读取次数
自定义域名：绑定备案域名，国内访问更稳定

6.3.2 优势

流量免费：图片被看多少次都不花钱，不用担心爆账单
容量够大：免费10GB，个人用完全够
全球加速：全国各地访问速度都不错
完全可控：自己的存储，不用担心图床跑路删数据
可扩展：以后可以加水印、缩图、鉴权等功能

6.3.3 怎么用

在R2里创建一个存储桶
把图片上传进去
绑定自定义域名，开启CDN
图片地址就是 https://你的域名/图片名.jpg

还可以搭配一个开源的图床管理面板，比如Cloudflare R2 Image Manager，上传、管理、复制链接都很方便。

对于小程序开发者来说，把所有商品图、素材图都放R2上，能省一大笔对象存储和流量费。

6.4 场景四：接口代理与加速

很多时候我们需要调用第三方接口，但直接访问很慢，甚至访问不了。这时候就可以用Cloudflare Workers做一层代理，实现加速和中转。

6.4.1 常见场景

境外AI接口加速：比如OpenAI、Anthropic的接口，国内直接访问慢、超时，用Worker中转一下，速度提升明显
境外API中转：调用境外的第三方服务，比如天气、股票、地图，通过Worker中转优化线路
接口封装：把多个第三方接口封装成一个，减少前端请求次数
跨域解决：第三方接口不支持跨域，用Worker代理一下就解决了

6.4.2 原理

小程序/前端不直接请求目标接口，而是请求你的Worker地址。 Worker收到请求后，代替你去请求目标接口，拿到结果再返回给你。 Worker跑在Cloudflare的边缘节点上，走Cloudflare的专线网络访问境外接口，比用户直接连快很多。

就像你国际快递直接寄很慢，找个转运公司，走他们的专属通道，就快很多。

6.4.3 注意事项

合规问题：代理境外敏感接口有合规风险，仅限合法合规的业务使用
安全问题：不要把密钥写在前端，密钥放在Worker里，前端只请求Worker
不要滥用：不要用来做违法违规的代理服务，会被封号

6.5 场景五：给现有网站加防护和加速

如果你已经有网站了，服务器放在阿里云、腾讯云或者其他地方，也能用Cloudflare。不用搬服务器，不用改代码，只要改一下DNS解析，就能获得加速和防护。

6.5.1 能获得什么

免费DDoS防护：再也不怕被人打网站了
CDN加速：静态资源缓存到边缘，网站打开更快
免费HTTPS证书：自动签发续期，不用自己买证书
WAF防火墙：挡住常见的黑客攻击
图片优化：自动压缩图片，提升加载速度
访问统计：详细的访问数据、流量分析

6.5.2 怎么接入

非常简单，三步搞定：

在Cloudflare添加你的域名
去域名注册商那里，把DNS服务器改成Cloudflare给的两个地址
等待生效，一般几小时到一天

生效之后，所有流量都会先经过Cloudflare，再到你的源服务器。全程不用改网站代码，不用动服务器，零侵入。

很多人觉得自己的小网站没人攻击，没必要。其实现在自动化的扫描、攻击特别多，只是你不知道而已。接入Cloudflare，免费多一层防护，何乐而不为。

6.6 场景六：定时任务与自动化脚本

很多时候我们需要跑一些定时脚本：

每天早上爬取当天的天气数据存起来
每天自动签到领积分
定时备份数据库到R2
定时监控网站是否能正常访问

以前做这个，你得有台服务器一直开着，挂个crontab。服务器关了，定时任务就停了。现在用Cloudflare Workers + Cron Triggers，完全不用服务器。

6.6.1 怎么用

写好你的Worker脚本，实现要做的事情
在后台配置定时触发器，比如“每天早上8点执行”
保存生效，到点自动运行

支持标准的Cron表达式，想什么时候跑就什么时候跑。免费版每天最多可以设置3个定时任务，完全够用。

6.6.2 优势

不用服务器：不用一直开着机器，省电省钱
稳定可靠：Cloudflare全球节点调度，不会漏执行
免费够用：免费额度足够跑很多轻量任务
全球部署：哪里的任务都能跑

对于个人开发者来说，这简直是神器。再也不用为了跑个定时脚本，专门买一台服务器了。

6.7 场景七：个人网络加速与安全

Cloudflare不只是给站长和开发者用的，普通用户也能用它的产品。就是 WARP 客户端。

6.7.1 WARP是什么

WARP是Cloudflare推出的个人网络工具，手机、Windows、Mac都能用。它会把你的网络流量，通过Cloudflare的全球网络进行优化和加密。

6.7.2 能干嘛

保护隐私：公共WiFi下，防止运营商和黑客窃听你的流量
优化速度：通过Cloudflare的智能路由，让访问很多网站更快
更安全：内置恶意网站拦截，防止钓鱼和病毒
免费基础版：基础功能完全免费，够用了

6.7.3 注意

WARP不是翻墙工具，不能用来访问境外被屏蔽的网站。它的核心是优化和加密，不是绕过监管。正常上网用它，能提升安全性和一定的速度体验。

第七部分新手避坑指南：90%的人都会踩的坑

Cloudflare虽然好用，但新手很容易踩坑。很多人听别人说“Cloudflare天下第一”，兴冲冲去用，结果发现速度慢、打不开、小程序用不了，然后就说它不好用。

其实不是它不好用，是你用错了姿势。这一章，我把新手最容易踩的7大类坑，全部列出来，告诉你为什么、怎么避。

7.1 域名与备案坑

这是国内用户踩得最多的坑，没有之一。

坑1：以为workers.dev能直接用在国内业务

很多新手写完Worker，拿着 xxx.workers.dev 这个域名就去用，结果发现：

小程序里配置不了，提示域名未备案
国内访问时快时慢，经常超时
有时候直接打不开

为什么？ 因为 *.workers.dev 是境外域名，没有ICP备案，而且默认解析到境外节点。国内网络环境下，不稳定是正常的。

避坑方法：

只做海外业务，可以直接用默认域名
做国内业务、小程序，必须绑定自己的备案域名

坑2：域名没备案就想接小程序/国内网站

很多人不知道小程序的备案要求，域名买了直接解析到Cloudflare，然后去小程序后台配置，发现根本通不过。

微信硬性规定：所有业务域名、接口域名、下载域名，必须完成ICP备案。没有备案的域名，连配置都不让你配置，更别说真机调用了。

避坑方法：

先备案，再上线。域名买了之后，立刻走备案流程
备案必须在国内注册商做，Cloudflare不提供备案服务
备案通过后，再把DNS迁到Cloudflare，不影响备案状态

坑3：随便买个域名就能备案？

不是所有域名都能备案。比如 .io、.cc、.app 这些后缀，有些不能在国内备案。还有境外注册商买的域名，要先转回国才能备案。

避坑方法：

买域名优先选 .com、.cn、.net 这些常见后缀
优先在阿里云、腾讯云等国内注册商买域名，备案方便
买之前查清楚这个后缀能不能备案

7.2 国内访问速度坑

很多人被“全球最快”、“300+节点”洗脑，以为Cloudflare在国内也一定很快。用了之后发现，怎么还不如国内的云服务器快？

坑1：免费版国内速度也很快

真相是：免费版的Cloudflare，国内访问默认走的是境外节点（一般是香港、新加坡、日本）。国内用户访问，数据要出境再回来，延迟自然高。一般国内一线城市，免费版延迟在80-150ms左右，二三线城市可能更高。这个速度做工具类、内容类小程序够用，但和国内云服务器的20-30ms延迟比，肯定是比不了的。

为什么会这样？ 因为国内节点是企业版中国网络的专属功能，免费版和Pro版都用不到。国内节点需要合规资质，成本更高，只对企业客户开放。

坑2：付费就能用国内节点？

不是。你买Pro版、Business版，也用不到中国大陆境内的节点。只有单独开通「中国网络」附加服务，并且域名完成备案，才能用到国内节点。而这个服务，只对企业客户开放，价格很高，个人和小团队基本不用考虑。

优化免费版国内速度的方法

虽然免费版没有国内节点，但也有一些优化手段：

绑定优质线路的域名：通过一些解析优化，让请求走更近的境外节点
开启Argo：付费开通Argo智能路由，走Cloudflare专线，速度会快一些
多用缓存：能缓存的都缓存，减少回源，边缘节点返回还是很快的
静态资源多，动态资源少：静态资源缓存后速度很快，尽量减少动态请求

总的来说：

个人项目、对延迟不敏感的业务，免费版够用
商业项目、对速度要求高的，老老实实上国内云

7.3 产品选型坑

Cloudflare产品很多，新手很容易乱用。明明该用A产品，结果用了B产品，又慢又贵还不好用。

坑1：什么都往Workers里塞

Workers很强大，但不是万能的。很多人觉得“反正免费，什么都往里放”，结果遇到各种问题：

复杂计算跑一半超时了
大文件处理内存不够
长连接支持不好

记住Workers的边界：

适合：轻量API、简单逻辑、数据转发、快速响应
不适合：CPU密集型计算、大文件处理、长耗时任务、复杂事务

坑2：用KV当数据库用

KV读很快，但写很慢，而且不能复杂查询。新手图省事，什么数据都往KV里塞：

存用户列表，想按昵称搜索 → 搜不了，只能按键查
频繁写入数据 → 写入慢，还容易超额度
存大量结构化数据 → 管理混乱，维护困难

正确选型：

结构化数据、需要查询 → 用D1
键值对、读多写少、配置项 → 用KV
文件、图片、大对象 → 用R2

坑3：R2存大量小文件

R2按操作次数计费，读写都是按次算钱。如果你存了几十万张小图片，每次请求都要读很多次，操作次数费用可能会比存储费还高。

优化方法：

小文件尽量合并，或者搭配CDN缓存，减少回源R2的次数
大量小文件场景，算好成本再用

7.4 安全与合规坑

坑1：用了Cloudflare就绝对安全了

没有绝对的安全。 Cloudflare能挡住绝大多数常见攻击，但不是万能的。

你的业务逻辑有漏洞，比如密码明文存、SQL注入，WAF不一定全能挡住
社工攻击、账号被盗，Cloudflare管不了
高级的、针对性的攻击，免费版防护能力有限

正确认识： Cloudflare是加分项，不是免死金牌。该做的代码安全、业务安全，还是要做好。

坑2：数据存在境外也没关系

很多人把用户数据存在D1、KV里，觉得没问题。但根据国内法规，收集国内用户的个人信息，原则上应当存储在境内。尤其是敏感个人信息，必须存在境内。

建议：

个人学习、非盈利项目、不收集敏感信息，问题不大
商业项目、收集用户隐私数据，尽量用国内云服务
不要把身份证、手机号、银行卡等敏感信息存在境外节点

坑3：用Workers做代理万能

很多人用Workers做各种接口代理，觉得没人管。实际上，代理服务是有监管要求的。尤其是代理境外网站、提供翻墙服务，是明确违法的。

红线不能碰：

不要做翻墙代理
不要代理违法违规内容
不要用来做垃圾邮件、恶意爬虫

轻则封号，重则承担法律责任。

7.5 成本坑

很多人以为Cloudflare全都是免费的，结果某天收到巨额账单，吓一跳。其实免费版有明确的额度限制，超出了就要花钱。只要你了解规则，完全可以控制住成本。

坑1：免费版永远够用

免费版额度看起来不少，但也不是无限的：

Workers：每天10万次请求，10万毫秒CPU时间
D1：每天10万次读，1000次写
R2：10GB存储，每月1000万次读
Pages：每月500次构建

个人小项目确实够用，但如果流量大了、用户多了，超出是分分钟的事。

坑2：超出免费额度很贵

其实Cloudflare的付费价格很便宜，只是很多人没了解过：

Workers：超出后每100万次请求0.5美元，很便宜
R2：存储每GB每月0.015美元，非常便宜
D1：价格也很低

正常使用，哪怕超出免费额度，一个月也就几美元，比买云服务器便宜多了。只要不是恶意刷量，不用担心账单爆炸。

避坑建议

设置用量告警：在后台设置预算提醒，超了会发邮件通知你
开启缓存：能缓存的都缓存，减少Worker执行和数据库读取
合理选型：静态资源走CDN，不要每次都跑Worker
防刷：加频率限制，防止被人恶意刷请求

7.6 常见误区澄清

最后，澄清几个流传很广的误区。

误区1：Cloudflare是云服务器厂商？

不是。它不卖云服务器，不租给你远程电脑。它做的是网络边缘的加速、安全、计算，是在你和源站之间加一层。它的计算产品是Serverless函数，不是可远程登录的虚拟机。

误区2：Cloudflare会偷我数据？

正规公司不会干这种事。 Cloudflare是美国上市公司，有严格的隐私政策和合规要求。当然，从技术上讲，流量经过它的节点，它能看到内容。所以特别敏感的数据，建议端到端加密。普通网站、小程序的数据，完全不用担心。

误区3：免费版会不会哪天就没了？

大概率不会。免费版是Cloudflare的核心战略，靠免费版吸引海量用户，培养生态，再转化付费客户。已经免费了十几年了，而且越免费功能越多，短期内不会取消。

误区4：国内不能合法使用？

可以合法使用。只要你的域名备案了、业务合规、不做违法的事，正常使用完全没问题。很多跨国企业、外资公司，都在合法使用Cloudflare的中国网络服务。个人用户正常搭博客、做小程序后端，也没问题。

第八部分为什么边缘计算是未来？Cloudflare的野心

讲到这里，你已经对Cloudflare有了全面的了解。但可能你还有个疑问：不就是个CDN加安全吗？为什么它能做到这么大？为什么大家都说边缘计算是未来？

这一章，我们站在更高的视角，看看互联网的发展趋势，以及Cloudflare的终极野心。

8.1 从中心化到分布式：互联网的发展趋势

互联网发展到今天，其实经历了三轮大的架构演变：

第一代：大型机时代（中心化）

几十年前，计算都是集中在大型机里。所有人用终端连到同一台大型机，所有计算都在中心完成。优点是管理方便，缺点是贵、扩展难、单点故障风险大。

第二代：云计算时代（半中心化）

最近二十年，云计算兴起。计算不再集中在某一台大型机，而是集中在少数几个云厂商的数据中心里。用户按需租用，弹性扩容，成本大幅降低。但本质上还是中心化的——数据和计算，都集中在少数几个偏远的数据中心里。用户要访问，就得跑很远的路。

第三代：边缘计算时代（分布式）

现在，我们正在进入第三代：边缘计算。计算不再集中在中心机房，而是下沉到网络边缘，离用户越来越近。哪里有用户，哪里就有计算能力。

为什么会这样发展？因为用户对速度的要求越来越高，对延迟越来越敏感。

以前网页慢个几秒，大家都能忍
现在APP加载超过1秒，用户就会流失
未来的AR/VR、自动驾驶、物联网，对延迟的要求是毫秒级

中心机房再大，也解决不了物理距离带来的延迟。唯一的办法，就是把计算搬到用户身边去。

这就是为什么所有人都说，边缘计算是下一代互联网的核心。

8.2 为什么边缘计算越来越重要？

有几个大趋势，在推着边缘计算往前走：

趋势一：实时应用越来越多

以前的互联网，是“请求-响应”模式，慢一点没关系。现在和未来的应用，对实时性要求越来越高：

云游戏：操作要立刻有反馈，延迟高了根本没法玩
AR/VR：画面延迟高了会晕
自动驾驶：指令晚几十毫秒，可能就是事故
实时翻译、实时互动直播、在线协作

这些应用，都要求极致的低延迟。只有边缘计算能满足。

趋势二：AI推理无处不在

以前AI是云端大模型，所有请求都发到中心机房去算。但未来，AI会无处不在：手机里、眼镜里、汽车里、设备里。很多AI推理，不需要超大模型，小模型在边缘就能跑，速度更快、隐私更好。比如实时美颜、实时语音翻译、智能摄像头识别。

把AI能力下沉到边缘，是必然趋势。 Cloudflare推出Workers AI，就是在布局这个未来。

趋势三：物联网设备爆发

未来会有几百亿、上千亿个物联网设备接入互联网。如果所有设备的数据都传到中心机房处理，带宽和算力根本扛不住。最好的方式，就是在边缘节点就地处理数据，只把关键结果传回中心。这就是边缘计算的巨大市场。

趋势四：数据隐私要求越来越高

用户越来越重视数据隐私，法规也越来越严。如果数据不用传到千里之外的中心机房，在本地边缘节点就处理完了，数据泄露的风险会小很多。边缘计算天然符合数据本地化的趋势。

8.3 Cloudflare的终极目标：成为全球互联网的操作系统

很多人觉得Cloudflare是做CDN的，是做安全的。其实这些都只是它的入口业务。它的终极野心，是成为全球互联网的操作系统。

什么意思？

Windows是电脑的操作系统，管理着电脑的硬件，给应用提供运行环境
安卓是手机的操作系统，管理手机硬件，给APP提供运行环境
Cloudflare想做的，是整个互联网的操作系统——管理全球的边缘网络和计算资源，给所有互联网应用提供运行环境

未来，开发者写应用，不用管服务器在哪、不用管网络怎么连、不用管安全怎么做。你只需要写好代码，部署到Cloudflare上，剩下的一切——网络、安全、算力、存储、全球分发——全由这个操作系统搞定。

全世界的用户，无论在哪，都能以最低的延迟、最安全的方式访问你的应用。

这就是Cloudflare的愿景：成为全球互联网的基础底座。现在它已经有了计算（Workers）、存储（R2/D1/KV）、网络、安全、AI能力，操作系统的零件已经凑齐了，剩下的就是不断完善和普及。

8.4 对普通人的影响

这个趋势，对我们普通人、普通开发者有什么影响？

1. 开发门槛越来越低

以前做一个全球可用的应用，你需要：

租全球多个地区的服务器
搭CDN
买安全设备
做数据同步
雇运维团队

现在你只需要写代码，剩下的Cloudflare全帮你搞定。一个人、一台电脑，就能做出服务全球用户的产品。个人开发者和小团队的能量，被无限放大了。

2. 成本越来越便宜

以前带宽、服务器、安全，都是巨大的成本。现在边缘计算把成本摊薄了，免费就能用，付费也很便宜。创业的门槛越来越低，一个好点子，几十块钱成本就能跑起来验证。

3. 用户体验越来越好

未来的应用会越来越快、越来越稳。无论你在世界哪个角落，都能享受到毫秒级的响应速度。攻击、卡顿、加载慢，这些问题会越来越少。

第九部分新手学习路径：从零开始上手Cloudflare

看到这里，你可能已经跃跃欲试，想自己动手玩玩了。但又不知道从哪下手，怕太复杂。别担心，我给你规划了一条循序渐进的学习路径，照着走就行，非常简单。

9.1 第一步：注册账号，熟悉后台

先从最简单的开始，不用写代码。

去Cloudflare官网注册一个账号，用邮箱就行，免费
随便添加一个域名（没有的话先不添加，也能逛后台）
点点左边的菜单，看看都有哪些功能，大概有个印象

不用都看懂，先熟悉界面，知道各个功能大概在哪就行。

9.2 第二步：先从CDN和免费证书玩起

如果你有自己的域名和网站，这是最值得先做的。

把你的域名添加到Cloudflare
按照提示，去域名注册商修改DNS服务器
等待生效，一般几小时
开启SSL/TLS，选“完全”模式
开启CDN缓存（默认就是开的）
开启WAF免费规则

做完这几步，你的网站就拥有了：

全球CDN加速
免费HTTPS证书
DDoS防护
基础WAF防护
详细的访问统计

不用改代码，不用动服务器，就能获得质的提升。这是性价比最高的一步。

9.3 第三步：用Pages搭第一个静态网站

如果你想做自己的博客、官网，这一步一定要试。

去Github注册个账号，建一个仓库
选一个静态网站生成器，比如Hexo，跟着教程生成一个博客
把代码推送到Github仓库
打开Cloudflare Pages，绑定你的仓库
配置构建命令，点击部署

等几分钟，你的博客就上线了，有免费的二级域名可以访问。还可以绑定自己的域名，开启HTTPS。全程不用买服务器，一分钱不花。

做完这一步，你就拥有了一个完全属于自己的、全球加速的个人网站。

9.4 第四步：写第一个Workers函数

等熟悉了基础操作，就可以试试写代码了。不用写复杂的，从最简单的Hello World开始：

进入Workers & Pages，创建一个Worker
系统会自动生成一个示例代码，直接点部署
访问分配的域名，看看返回的内容
修改代码，改成你想要的内容，重新部署

先感受一下边缘函数的部署和运行，体会一下“不用服务器也能跑代码”的感觉。然后可以慢慢写点简单的接口，比如返回当前时间、返回随机文案、做个简单的计算器。

等熟练了，再试着连接D1数据库，写完整的增删改查接口。

9.5 第五步：组合产品做完整项目

当你把单个产品都玩熟了，就可以组合起来，做一个完整的小项目了。比如：

一个简单的待办清单小程序：Workers + D1
一个图床工具：R2 + Workers + Pages
一个简单的留言板：Pages + D1 + Workers Functions

从简单的开始，慢慢增加功能。做完整项目的过程，是进步最快的。

9.6 学习资源推荐

官方文档：Cloudflare的官方文档写得非常好，有中文，是最好的学习资料
官方教程：官网有很多手把手的教程，跟着做就行
开发者社区：Github、掘金、知乎，有很多大佬分享的实战教程
动手做：最重要的还是动手，光看没用，做两个项目就全会了

结语：更好的互联网，每个人都能享受

15年前，三个年轻人从一个反垃圾邮件的项目出发，想让互联网更安全一点。 15年后，他们建起了一张覆盖全球的边缘网络，让几千万个网站更快、更安全，让个人开发者不用买服务器也能做产品。

Cloudflare最酷的地方，不是它技术有多牛，而是它把以前只有大公司才用得起的能力，免费开放给了所有人。

以前几十万的DDoS防护，现在免费
以前几百块一年的SSL证书，现在免费
以前贵得离谱的CDN流量，现在免费
以前要自己搭服务器才能做后端，现在免费就能做

它真正在践行自己的使命：帮助建设一个更好的互联网。而我们每个人，都是这个更好互联网的受益者。

希望这篇长文，能帮你推开边缘计算的大门。无论你是只想给自己的网站加个速，还是想做自己的小程序创业，都能从Cloudflare身上获得价值。

互联网的下一个时代，是边缘计算的时代。早点了解，早早上车，你就能比别人先看到未来。

分清Vercel：
- **Cloudflare**：先自己掏钱修了覆盖全球的公路网，再在路边开了300多家连锁便利店，从安全防护、快递加速起家，慢慢在店里加了货架、店员、后厨、储物仓，本质是**做底层网络基建的公司**。
- **Vercel**：专门做「高端现制甜品连锁站」，主打把前端蛋糕做得又快又好吃，开发者体验拉满，但它自己不修路、不建大物流网，底层的店面和运输大多是租AWS等云厂商的，本质是**前端开发者工具公司**。

---

## 一、Vercel到底是干嘛的？
Vercel 前身叫 ZEIT，是前端圈火起来的部署神器，也是目前最火的React框架 **Next.js 的母公司**。

它的核心卖点就一个：**把前端项目的部署体验做到了极致**。
你写好了React、Vue、Next.js的前端代码，把仓库往Github一放，在Vercel点一下绑定，几十秒就自动构建、部署、上线，自动配好HTTPS、自动CDN加速。每次改代码提交，自动重新部署，还自动给每个分支生成独立预览链接，团队协作特别方便。

简单说：它是前端开发者的「一键上线神器」，所有功能都围绕「让前端开发上线更爽」来做。

---

## 二、和Cloudflare的7个核心区别
### 1. 起家业务与核心定位完全不同
这是最本质的差别：
- **Cloudflare**：从「DDoS防护+CDN加速」起家，先铺网络再做应用。它的根是网络安全公司，计算、存储、托管都是在全球网络底座上长出来的附加功能。就像先修了全国高速网，再沿路开便利店。
- **Vercel**：从「静态站点一键部署」起家，先做开发者体验再补底层。它的根是前端工具公司，所有能力都服务于前端项目的部署和渲染，底层的服务器、带宽大多租用AWS的基础设施，自己不做物理基建。

### 2. 底层节点数量差了一个量级
两者都叫“全球边缘网络”，但覆盖密度天差地别：
- **Cloudflare**：全球335+个城市都有自有服务器节点，**每个节点都能跑代码、存缓存**，用户在哪，计算就在哪。
- **Vercel**：全球只有约120个接入点（POP），其中真正能跑代码的计算区域只有18-20个，大部分节点只能做缓存和TCP接入，请求要通过专线转到后方的计算区处理。

打个比方：Cloudflare是每个小区楼下都有便利店，店员当场就能处理业务；Vercel是市区只有几个中央厨房，街边只有自提柜，你下单后要从中央厨房做好送过来。

### 3. 产品广度完全不在一个维度
- **Cloudflare**：全家桶级别的产品矩阵。CDN、WAF防火墙、DDoS防护、DNS、边缘函数、SQL数据库、对象存储、视频托管、企业组网、零信任安全……从个人站长到世界500强的网络需求，基本都能覆盖。不止做前端，后端、网络、安全、企业服务全做。
- **Vercel**：产品非常聚焦，就围绕前端部署和全栈Web应用。核心就是静态托管、Serverless函数、边缘函数、预览部署、Next.js优化。没有独立的安全产品、没有企业组网、数据库和存储也都是集成第三方为主。

一句话：**Cloudflare什么都做，Vercel只深耕前端这一块。**

### 4. 边缘计算的定位不同
两者都有基于V8隔离的边缘函数，但用法天差地别：
- **Cloudflare Workers**：定位是**独立的后端计算平台**。你可以完全不用其他服务器，只用Workers+D1+R2就搭出完整后端，支持复杂的业务逻辑，免费额度也足以支撑中小项目。
- **Vercel Edge Functions**：定位是**前端的辅助中间件**。更多用来做页面边缘渲染、权限校验、路由跳转、A/B测试，配合前端页面使用，很少有人单独拿它写完整的后端接口。而且它的CPU时长限制更严，单请求只有50ms左右的计算时间。

### 5. 国内访问体验差距巨大
这对国内用户来说是最致命的差别：
- **Cloudflare免费版**：国内默认走香港/新加坡等境外节点，延迟80-150ms，时快时慢，但绝大多数时候能正常访问。
- **Vercel免费版**：国内访问非常不稳定。默认的`*.vercel.app`域名经常被运营商DNS污染，手机4G、普通家庭宽带经常直接打不开、超时报错，延迟普遍300ms以上，部分地区完全无法访问。

如果是做国内用户的小程序、正式网站，Vercel免费版基本没法直接当生产环境用。

### 6. 免费额度的侧重点不同
| 项目 | Cloudflare 免费版 | Vercel 免费版（Hobby） |
|------|-------------------|------------------------|
| 带宽/流量 | Pages 无限流量 | 每月 100GB |
| 构建资源 | Pages 每月500次构建 | 每月6000分钟构建时长 |
| 边缘函数 | 每天10万次请求 | 每月100万次调用 |
| 内置数据存储 | D1 数据库5GB + R2 对象存储10GB | 无内置数据库，需外接第三方 |

简单说：流量大的项目用Cloudflare更划算，前端构建多的项目Vercel更宽松。

### 7. 小程序场景的合规性
两者在这一点上是一样的：
- 自带的默认域名（`*.workers.dev` / `*.vercel.app`）都没有ICP备案，**都不能直接填到微信小程序后台的合法域名里**。
- 要在小程序里用，都必须绑定你自己完成ICP备案的自定义域名。

---

## 三、最容易混淆的点：Cloudflare Pages vs Vercel
很多人会把这两个拿来比，因为它们都能一键绑定Github部署静态网站，体验很像。
确实，在「静态站点托管」这个单一功能上，它们是直接竞品，但差异依然很明显：

1. **定位不同**
   - Pages 只是Cloudflare庞大产品矩阵里的一个小功能，是全家桶的一环；
   - 部署托管是Vercel的全部核心业务，所有资源都往这上面倾斜。

2. **框架适配不同**
   - Vercel 对 Next.js 是原生级优化，服务端渲染、增量静态再生、边缘渲染这些功能开箱即用，体验碾压所有其他平台；
   - Cloudflare Pages 对通用框架都支持，但对Next.js的高级功能支持不如Vercel完整。

3. **网络与成本不同**
   - Pages 带宽无限，全球节点更多，国内访问相对更稳定，适合流量大的站点；
   - Vercel 带宽有限，但前端开发流程更顺滑，适合团队协作的前端项目。

4. **生态扩展不同**
   - Pages 部署完可以无缝对接Cloudflare全家桶：开WAF、配DDoS防护、接R2存储、写Workers函数，不用换平台；
   - Vercel 要扩展后端、存储、安全，大多需要集成第三方服务。

---

## 四、回到你的需求：做微信小程序，选哪个？
结合你一直关心的小程序场景，直接给明确结论：

### 1. 做小程序后端API
**优先选 Cloudflare Workers + D1。**
- 节点更多、国内相对更稳定，接口成功率更高；
- 有完整的数据库、存储配套，一套就能搭出完整后端；
- 免费额度更充足，小流量项目基本不花钱。

Vercel的函数更适合配合前端页面用，单独拿来做小程序后端，既不好用，国内访问也容易翻车。

### 2. 部署小程序的配套H5页面
- 如果用 Next.js 开发：选 Vercel，开发体验最好；
- 如果用其他框架、或者国内用户多：选 Cloudflare Pages，访问更稳。

### 3. 正式商用、国内用户为主
两者都不是最优解，更建议用国内云平台（腾讯云、阿里云、微信云开发），合规性、稳定性、速度都更有保障。

---

## 最后一句话总结
- 搞前端、做网站、用Next.js、追求开发体验 → 选 Vercel
- 搞后端、做接口、要安全、要全球网络、要省钱 → 选 Cloudflare
- 做国内小程序的后端接口 → 优先 Cloudflare，Vercel免费版慎选

Qiu

前言：为什么你每天上网，都绕不开这家公司？

第一部分 Cloudflare的前世今生：从反垃圾邮件项目到全球互联网底座

1.1 故事的起点：一个追踪垃圾邮件的校园项目

1.2 三个创始人的碰撞：技术+商业的完美组合

1.3 从哈佛商业计划冠军到正式上线

1.4 十五年进化之路：从CDN厂商到连接云平台

第一阶段（2010-2015）：安全+加速的基础服务商

第二阶段（2016-2020）：边缘计算平台的崛起

第三阶段（2021-至今）：全球连接云（Connectivity Cloud）

1.5 今天的Cloudflare：全球互联网的隐形管家

第二部分 先搞懂底层逻辑：互联网是怎么跑起来的？

2.1 你打开一个网页的全过程：快递寄件的比喻

2.2 为什么网站会慢？距离远、路不好、仓库忙

原因一：物理距离太远

原因二：网络路不好走

原因三：服务器忙不过来

2.3 为什么网站会挂？黑客攻击和流量洪峰

第一种：正常流量洪峰

第二种：恶意DDoS攻击

2.4 传统解决方案的痛点：贵、麻烦、效果差

方案一：多买几台服务器，多建几个机房

方案二：买传统CDN服务

方案三：买硬件防火墙防攻击

方案四：用云服务器

第三部分 核心概念大白话：用连锁便利店讲透所有术语

3.1 边缘节点：开在你家楼下的便利店

3.1.1 什么是“边缘”？互联网的最后一公里

3.1.2 边缘节点是谁的？房子租的，设备自己的

3.1.3 全球335个城市的便利店网络

3.1.4 中国大陆的特殊情况：和京东云合作的便利店

3.2 静态资源：货架上预包装好的商品

3.2.1 大白话定义

3.2.2 互联网里的静态资源有哪些？

3.2.3 静态资源的核心特点

3.2.4 常见误区：静态就是不能动？

3.3 动态资源：后厨现做的定制餐

3.3.1 大白话定义

3.3.2 互联网里的动态资源有哪些？

3.3.3 动态资源的核心特点

3.3.4 为什么早期CDN管不了动态资源？

3.4 CDN内容分发网络：全国连锁便利店配送体系

3.4.1 什么是CDN？

3.4.2 CDN的完整工作流程

3.4.3 关键指标：缓存命中率

3.4.4 Cloudflare的CDN强在哪？

3.5 边缘函数：便利店里的全能店员

3.5.1 从只能卖货到能干活：便利店的进化

3.5.2 什么是边缘函数？

3.5.3 边缘函数的核心优势

3.5.4 Cloudflare Workers：边缘函数的标杆产品

3.6 Anycast任播技术：全国统一客服电话

3.6.1 传统IP：一个号码对应一个总店

3.6.2 Anycast任播：全国分店同一个号码

3.6.3 Anycast的额外好处：天然抗攻击

3.6.4 为什么不会接错？

3.7 一张表总结所有核心概念

第四部分 Cloudflare全家桶详解：60+产品一次讲明白

4.1 加速与缓存类产品：让你的网站飞起来

4.1.1 CDN：基础款连锁配送

4.1.2 Cache Reserve：超大备用仓库

4.1.3 Argo Smart Routing：智能导航，绕开堵车路段

4.1.4 图片优化全家桶：自动给商品减重

① Polish：自动压缩图片

② Resize：按需调整图片尺寸

③ Mirage：移动端图片优化

4.1.5 Rocket Loader：让网页JS飞起来

4.2 安全防护类产品：给你的网站装铜墙铁壁

4.2.1 DDoS防护：挡住上门闹事的混混

4.2.2 WAF Web应用防火墙：智能安检门

4.2.3 Bot Management机器人管理：分辨真人还是黄牛

4.2.4 Turnstile：无感验证码，不用再点图片

4.2.5 SSL/TLS证书：给包裹上锁，半路没人能拆开看

4.2.6 DNS解析服务：互联网的地址本

4.3 开发者平台类产品：不用服务器也能做应用

4.3.1 Cloudflare Workers：边缘店员的核心

Workers能做什么？

Workers的局限

4.3.2 Workers KV：便利店的小储物柜

KV的特点

第二部分先搞懂底层逻辑：互联网是怎么跑起来的？

第三部分核心概念大白话：用连锁便利店讲透所有术语

第五部分全程拆解：一次小程序访问到底经历了什么？

第六部分实战应用场景：普通人能用Cloudflare干什么？