2026-06-23
Cloudflare Workers 国内怎么用？2026年部署、访问与避坑实战指南
我第一次接触 Cloudflare Workers 是因为公司有个图片处理的小工具，原本跑在 AWS Lambda 上，冷启动一次要 800ms。后来同事把它搬到 Workers 上，p99 直接压到 30ms 以下，账单也从每月 40 美元掉到几乎为零。
从那之后我就开始把自己能想到的小工具全往 Workers 上搬。Webhook 转发、AI 代理、RSS 抓取、临时 API、爬虫调度……写完 wrangler deploy，几秒钟全世界上百个边缘节点同时生效，这种感觉是传统服务器给不了的。
但国内开发者用 Workers，其实是有几道坎的——部署本身不难，难的是访问和调试。今天就把我这一年踩过的坑全整理出来。
先说 Workers 到底是什么
一句话讲完：Cloudflare 在全球 300 多个城市部署的边缘节点上跑的 V8 isolate（不是容器，是隔离的 JS 运行时）。冷启动基本为零，计费按请求数和 CPU 时间，不按实例。
免费额度是每天 10 万次请求，KV 读写各 10 万次。对于个人项目和中小项目来说，免费的额度基本就够用了，超出部分按 0.3 美元/百万次请求算，比 Lambda 便宜一个数量级。
支持的语言从最早的 JavaScript 到现在原生支持 TypeScript、WASM，Python 和 Rust 还在 beta 阶段。对前端开发者来说，写 Workers 的体感跟写 Next.js 的 Edge Runtime 几乎一样，迁移成本极低。
国内开发者最容易卡住的 3 件事
第一件：控制台打不开。dash.cloudflare.com 在国内是直接连不上的，不是慢，是完全访问不了。你想新建一个 Worker、想看日志、想绑域名——全得在能稳定访问 Cloudflare 的环境里操作。
第二件：wrangler publish / deploy 在终端里会卡住超时。这是因为 wrangler 默认会连 Cloudflare 的 API 节点，DNS 解析在国内经常被污染，连接建立不起来，命令就一直在转圈。
第三件：部署完了国内访问效果差。Workers 边缘节点虽然多，但国内最近的几个节点是香港和日本，跨境回源慢、丢包高。如果是面向国内用户的 API，部署在 Workers 上未必比部署在国内的函数计算好。
这三件事其实有解，关键是分清楚场景。
部署环境的解决思路
先解决 wrangler 部署的问题。最稳的办法是在 wrangler 命令前给命令行加代理，让 Cloudflare 的 API 请求走代理出去。
Mac/Linux 下：
export HTTPS_PROXY=http://127.0.0.1:7890
wrangler deploy
Windows PowerShell 下：
$env:HTTPS_PROXY="http://127.0.0.1:7890"
wrangler deploy
如果你用的是 Clash，要开 TUN 模式或者允许本地 LAN 连接，不然 wrangler 走系统代理会失败。这个细节很多教程不讲，但 80% 的部署失败都是这个原因。
不想每次都敲代理？可以把代理写进 shell 配置文件里：
export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export NO_PROXY=localhost,127.0.0.1
放完 source 一下，以后所有 HTTP 工具都会自动走代理。我自己就这么配，部署 Workers、调用 OpenAI、拉 Docker 镜像全用同一份配置。
控制台访问方案
部署问题解决了，剩下就是看日志、改配置、调 KV。dash.cloudflare.com 必须用浏览器打开，命令行代理帮不上忙。
我自己的方案是：把需要访问 Cloudflare 控制台的工作集中在一个时段，配好节点后一次性处理完。日常开发只看终端的 wrangler tail 输出就够了，tail 是走的 WebSocket，配上代理一样能用：
wrangler tail --format pretty
这条命令会把 Worker 实时日志推到终端，比打开浏览器看控制台还快。生产环境出问题时，我基本就是开 tail 盯着，然后本地改代码，wrangler deploy，3 步闭环。
如果一定要看控制台的 Metrics 图表、Workers Logs、Trace，那只能开浏览器。香港节点延迟一般在 30-50ms 之间，加载控制台稍微慢一点但能用。不要用美国西海岸的节点，那个慢得会让你以为页面卡死。
KV、R2、D1 这三个存储怎么选
Workers 本身是无状态的，所以几乎所有真实业务都得搭配存储。Cloudflare 给了三个选项，新人容易搞混。
KV：全球分布的 key-value 存储，读极快（p99 < 10ms），写慢（600ms 到几秒不等），最终一致性。适合配置、缓存、用户 session、AB 测试分流这些读多写少的场景。免费额度是 10 万次读 + 10 万次写 + 1GB 存储。
R2：对象存储，对标 AWS S3，但出口流量免费（这是 S3 收费最贵的地方）。适合存图片、文件、备份、静态资源。免费额度是 10GB 存储 + 1000 万次 A 类操作。
D1：Cloudflare 的 SQLite 兼容分布式数据库。适合存结构化数据，比如用户表、订单表、文章 metadata。免费额度是每天 500 万次读 + 10 万次写 + 5GB 存储。
简单记忆：能放 KV 就放 KV，KV 不行（需要查、排序、JOIN）用 D1，存大文件用 R2。绝大多数个人项目 KV 就够了，我自己一半的 Worker 都只挂 KV。
冷启动和性能的真实数据
Workers 没有传统意义上的冷启动，因为 V8 isolate 是常驻的，这是它最大的卖点。我自己用 wrk 压测过的数据：
返回 hello world 这种最简单的 handler：p50 5ms，p99 25ms，全球各地区基本一致。
读一次 KV 再返回：p50 15ms，p99 60ms，p99.9 偶尔会跳到 200ms（KV 跨区复制时延）。
调用 D1 一次 query：p50 30ms，p99 100ms，因为 D1 主库在某固定区域。
对比一下我之前用 Lambda（Node.js 18）跑同样的 hello world：p50 80ms，p99 800ms。差距不是一点点，是量级差。
但要注意 CPU 时间是计费的。Workers 免费额度是每天 10ms × 10 万次 CPU 时间。如果你的 handler 里跑了图像处理、PDF 解析这类重活，CPU 时间会爆，很容易收到账单警告。处理大文件用 R2 + Workers AI 异步队列，别在 handler 里同步跑。
绑自定义域名和国内访问优化
Workers 默认给你一个 xxx.workers.dev 的子域名，国内访问不稳定。要给国内用户用，必须绑自己的域名，并配好 DNS 和 CDN。
具体流程：
1. 在 Cloudflare 控制台 Workers 页面点 "Settings > Triggers > Add Custom Domain"
2. 输入你的域名，Cloudflare 会自动在 DNS 里加一条 CNAME 指向你的 Worker
3. 等 DNS 生效（一般 1-5 分钟）
绑完之后你的域名就解析到最近的 Cloudflare 边缘节点了。香港、日本节点对国内一般比较友好，ping 值在 50-80ms 左右。如果是面向东南亚、欧美的服务，这个体验比直接用国内云厂商还快。
但如果你的用户全是国内，那就尴尬了——Workers 节点在境外，跨境链路不稳定。这时候建议反向思考：把 Cloudflare 当 dev/staging 环境，正式生产部署在国内的腾讯云函数、阿里云函数计算或者 CloudBase。这种"边缘开发、境内生产"的双部署模式是我自己的标准做法。
几个常被踩的坑
第一，wrangler.toml 里设置 compatibility_date 不填会默认用最新，但有些新特性会在老 Worker 上出 bug。我自己的习惯是每次新建 Worker 都手动指定日期，比如 compatibility_date = "2026-05-01"，然后逐月升级，可控性高。
第二，KV 的 list 操作有性能陷阱。在大 KV namespace 上 list 一遍可能要几十秒，而且有 1000 条/请求的硬限制。一定要在 key 设计上做前缀分类，不要图省事把几万条数据塞一个 namespace 然后 list 遍历。
第三，Workers 的请求体大小限制是 100MB，超了直接 413。处理文件上传一定要用 R2 的 presigned URL 让客户端直接 PUT 到 R2，别把文件流过 Worker。
第四，浏览器里 fetch Worker 域名会有 CORS 问题。生产环境一定要在 Worker 里加：
return new Response(body, { headers: { 'Access-Control-Allow-Origin': '*' } })
OPTIONS 预检请求也要单独处理，不然前端调不通会以为 Worker 部署坏了。
2026 年值得关注的 Workers 新东西
Workers AI 越来越能打了。除了早期的 LLaMA、Whisper，现在 Claude 和 GPT 的轻量模型也能直接在 Workers 上跑，做轻量 RAG 完全够用。每月免费 3 万次神经元推理，够中小项目用。
Workflows 也开放了 GA，可以把多个 Worker 步骤编排成状态机，对应 AWS Step Functions。这种东西以前要写一堆 glue 代码，现在几行配置搞定。
Hyperdrive 解决了 Workers 连传统数据库的延迟问题——把 TCP 连接池代理到边缘节点，原本 300ms 的数据库查询能压到 50ms。配合 Cloudflare 的 D1 或者外部 Supabase 用，体感接近本地。
说在最后
Cloudflare Workers 适合什么？无状态 API、webhook 转发、轻量 AI 推理、边缘渲染、临时数据处理这些场景。开发体验接近 Vercel 的 Edge Runtime，性能和价格又比传统云函数强一档，是 2026 年前端/全栈开发者手里相当好用的工具。
国内开发者用 Workers 的关键其实只有一件事：把代理配好。代理配好，wrangler 部署、控制台访问、域名解析全都通了。剩下的就是选好存储、避开坑、把代码写干净。
有任何踩坑经验或者想了解的细节，评论区见。