独立站边缘计算：Cloudflare Workers/Vercel Edge的应用场景与性能
一、边缘计算到底是什么，和CDN什么关系
传统CDN只做静态文件缓存，用户请求来了直接返回缓存。边缘计算在CDN节点上跑一小段JavaScript代码，在返回响应之前可以做逻辑判断：根据用户地理位置跳不同页面、根据cookie决定展示哪个版本、校验JWT是否有效。这层逻辑在离用户几十毫秒的节点上执行，不用回源站。
和服务端渲染（SSR）的区别：SSR在你自己的服务器上跑，全球用户都要跨越大洋连到那台服务器；边缘函数在全球300多个节点上同时跑，用户连最近的节点就行。对于跨境B2B独立站，这个距离差异直接决定了TTFB是100毫秒还是800毫秒。CDN和边缘的关系，见CDN全球加速。
反直觉的判断：边缘计算不是”更快的服务器”，它是”更小的服务器”。每个边缘函数的CPU时间有严格上限，不能做重计算。如果你把一个要跑200毫秒的数据库查询逻辑搬到边缘，结果会比在源站跑慢3倍以上——因为边缘节点到数据库的网络距离远。
| 执行环境 | 运行位置 | CPU时间上限 | 冷启动 | 数据库访问 | 成本模型 |
|---|---|---|---|---|---|
| 传统服务器（VPS） | 单一机房 | 无硬限制 | 无（常驻） | 本地/内网，快 | 包月，固定 |
| Cloudflare Workers | 全球300+节点 | 10毫秒免费/30毫秒付费 | 接近零（V8隔离） | 需连接外部数据库，慢 | 按请求数计费 |
| Vercel Edge Functions | 全球25+节点 | 最长30秒 | 10至50毫秒 | 支持Edge DB | 按调用时长计费 |
| AWS Lambda@Edge | 全球CloudFront节点 | 最长5秒 | 10至100毫秒 | 需走公网连RDS | 按请求+时长 |
二、三个真正值得用边缘计算的场景
第一个场景：按地理位置和语言做重定向。一个出海站，德国用户进来自动跳到/de/德语版，中东用户跳到/ar/阿拉伯语版。传统做法是在服务器上读IP库做判断，每个请求都要回源站。用Cloudflare Workers写10行代码，在边缘节点直接根据IP国家返回301，TTFB从400毫秒降到50毫秒。多语言站怎么配hreflang，见Hreflang多语言落地。
第二个场景：A/B测试分流。你想把首页做成两个版本，50%用户看A版本，50%看B版本。传统做法是在服务端读取cookie后决定渲染哪个版本。边缘做法更简单：Workers根据cookie哈希值，直接重写HTML中的资源路径或注入不同变量，源站完全无感知。分流本身在10毫秒内完成，不影响TTFB。
第三个场景：轻量鉴权和反爬。用户登录后发的请求，先在边缘校验JWT有效性，无效直接返回401，不回源站。这样源站只处理合法请求，带宽和CPU都省了。反爬也可以在边缘做：检测到可疑UA或请求频率过高，直接返回挑战页，不让请求到达源站。
| 场景 | 边缘实现方式 | 性能收益 | 开发工作量 | 建议优先级 |
|---|---|---|---|---|
| 地理重定向 | Workers读request.cf.country | TTFB降50至150毫秒 | 半天 | 高 |
| A/B测试分流 | Workers按cookie哈希分流 | 不增加TTFB | 1至2天 | 中 |
| JWT边缘鉴权 | 边缘验证token，无效直接拒 | 源站负载降20%至40% | 2天 | 高 |
| 反爬/限流 | 边缘检测UA和频率 | 恶意请求不回源 | 1天 | 高 |
| 个性化页面渲染 | 边缘拼装HTML片段 | 仅对重复片段有效 | 3至5天 | 低 |
三、两个不该用边缘计算的坑
第一个坑：把数据库查询搬到边缘。很多人觉得”边缘计算很高级”，把用户中心的查询逻辑也搬上去。结果边缘节点连的是远程数据库，一次查询的网络往返就要200毫秒，比源站本地查询慢5倍。边缘函数适合做”无状态、轻计算、靠缓存”的逻辑，不适合做”需要查数据库”的逻辑。
第二个坑：把整个SSR搬到边缘。Next.js的Edge Runtime模式确实可以在Vercel边缘节点跑React渲染，但渲染一个复杂页面的CPU时间可能超过100毫秒，撞上免费版限制，或者冷启动让首访用户多等50毫秒。复杂的服务端渲染仍然应该在源站跑，边缘只做轻量中间层。第三方脚本怎么治理，见第三方脚本治理。
场景化示例：一个出海SaaS产品，用户仪表盘页面需要查数据库渲染。团队一开始兴奋地用Vercel Edge Runtime重写了这个页面，结果发现边缘节点到他们的AWS RDS数据库延迟80毫秒，加上渲染时间，TTFB反而从250毫秒涨到了450毫秒。后来把仪表盘放回源站，只在边缘做登录校验和路由分流，TTFB才回到250毫秒。
| 坑 | 看起来的好处 | 实际后果 | 正确做法 |
|---|---|---|---|
| 数据库查询搬到边缘 | “离用户更近” | 边缘到DB网络远，延迟涨3至5倍 | DB查询留源站，边缘只做缓存读取 |
| 整站SSR跑在边缘 | “全球加速” | CPU超限/冷启动慢，TTFB反而涨 | 边缘只做中间层，渲染留源站 |
| 大量文件读写 | “本地处理” | 边缘无持久磁盘，内存有限 | 文件操作走对象存储API |
| 长计算任务 | “并行更快” | CPU超时直接1102错误 | 拆成小任务或走消息队列 |
四、成本与选型：Cloudflare Workers vs Vercel Edge
Cloudflare Workers和Vercel Edge Functions是目前独立站最常用的两个边缘平台。选型主要看你的技术栈和流量规模。Cloudflare Workers用V8 isolate，冷启动接近零，免费版每天10万次请求，非常适合做轻量路由和鉴权。Vercel Edge Functions和Next.js深度集成，如果你已经用Next.js，迁移成本最低，但冷启动比Workers慢。
成本上，Cloudflare付费版5美元/月起，含1000万次请求；Vercel Pro版20美元/月起，边缘函数按执行时间计费，流量大了账单会跳得快。中小B2B独立站月PV在10万以内，Cloudflare免费版基本够用。性能怎么监控，见站点监控与告警。
| 维度 | Cloudflare Workers | Vercel Edge Functions | AWS Lambda@Edge |
|---|---|---|---|
| 冷启动 | 接近零（V8） | 10至50毫秒 | 10至100毫秒 |
| 免费额度 | 10万请求/天 | 100GB-hours/月 | 100万请求/月 |
| 付费起步 | 5美元/月 | 20美元/月 | 按用量，无包月 |
| 开发语言 | JavaScript/TypeScript | JavaScript/TypeScript | Node.js/Python |
| 适合框架 | 纯函数/中间件 | Next.js深度集成 | AWS生态站 |
| 节点覆盖 | 300+城市 | 25+国家 | CloudFront全球 |
FAQ 常见问题
Cloudflare Workers免费版真的够用吗？
边缘函数和CDN缓存是什么关系？
Vercel Edge Functions和Cloudflare Workers哪个快？
边缘函数能做SEO优化吗？
边缘函数出错怎么回滚？
什么情况下边缘计算不会让站变快？
写在最后
边缘计算是一个”小而美”的优化手段，不是全站架构的革命。它解决的是”每个请求都要回源站”这个具体瓶颈，适合做轻量路由、鉴权、分流这类逻辑。如果你抱着”上边缘就能全站快一倍”的预期去做，大概率会失望——因为大部分慢，慢在数据库查询和第三方脚本，不在网络距离。
落地建议从一个最小场景开始：先用Cloudflare Workers做一个地理重定向，把德国用户自动导到德语版页面。这个改动半天就能上线，性能收益立竿见影，风险也最低。跑稳两周后，再考虑加A/B分流或边缘鉴权。不要一上来就想把整个站搬到边缘。
一句可以记住的话：边缘计算是离用户最近的快递站，不是离数据库最近的仓库——把分拣活放它那儿，别把仓库活也搬过去。