边缘计算与 CDN 选型Cloudflare Workers 与 Vercel Edge Functions 的实战对比一、边缘计算的本质是把计算从中心服务器搬到离用户更近的地方——但「更近」不是唯一需要考虑的因素过去十年里前端工程师的「运行环境」经历了几次重大扩展从浏览器到 Node.js 服务器到 Serverless 函数到现在的边缘计算。每一次扩展都让前端工程师能做的事情更多——但每一次扩展也带来了新的约束和新的决策。Cloudflare Workers 和 Vercel Edge Functions 是目前最主流的两个边缘计算平台它们都允许你在 CDN 的边缘节点上运行 JavaScript/TypeScript 代码让用户请求在离他最近的机房里被处理从而降低延迟。但它们在设计哲学、适用场景和开发体验上有明显差异。Cloudflare Workers 是一个通用的边缘计算平台它的编程模型是标准的 Web APIfetch、Request、Response可以处理任意 HTTP 请求适合做 API 代理、A/B 测试、个性化内容和边缘渲染。Vercel Edge Functions 是 Vercel 平台的一部分与 Next.js 的深度集成是它的核心优势——你可以直接在 Next.js 的项目里写边缘函数部署时自动分发到 Vercel 的全球边缘网络。但选型不能只看「能不能跑」。边缘计算平台的选择还需要考虑是否有你需要的 npm 包支持边缘环境的运行时通常不支持所有 Node.js API、是否有本地开发工具、是否有足够的可观测性日志、指标、错误追踪、以及最重要的——计费模式是否在你的预期流量下可接受。二、运行时差异WinterCG 标准与平台特有 API 的权衡flowchart TD A[边缘计算选型] -- B{主要使用场景?} B -- 独立 API/代理/中间件 -- C[Cloudflare Workers] B -- Next.js 边缘渲染/中间件 -- D[Vercel Edge Functions] B -- 需要 Node.js API -- E[考虑 Serverless 而非边缘] C -- F[基于 WinterCG 标准] D -- G[基于 Edge Runtime] F -- H[支持 Web API] G -- I[支持部分 Node.js API] H -- J[体积小/启动快] I -- K[与 Next.js 集成深]Cloudflare Workers 的运行时是基于 WinterCGWeb-interoperable Runtimes Community Group标准的它支持标准的 Web APIfetch、Request、Response、WebSocket但不支持大多数 Node.js 特有 API如fs、path、crypto——有替代的 Web Crypto API。这意味着如果你有一段代码用了fs.readFile它不能直接在 Cloudflare Workers 里跑你需要改写它。Vercel Edge Functions 的运行时是基于 Vercel 的 Edge Runtime 的它同样基于 WinterCG 标准但额外支持了一部分 Node.js 兼容层如process.env、Buffer。对于已经用 Next.js 的团队这个运行时的约束感更弱因为 Next.js 的中间件和边缘渲染功能本来就是在类似的约束下设计的。但运行时的差异在实际开发中影响最大的不是「能不能跑」而是「能用哪些 npm 包」。很多 npm 包在发布时没有考虑边缘环境它们可能依赖 Node.js 特有 API可能在打包时引入了不适合边缘环境的依赖。Cloudflare 提供了wrangler工具来做本地开发和打包它会在构建时检查依赖是否兼容边缘环境Vercel 则在部署时做类似的检查。三、开发体验对比本地开发、调试与部署开发体验是边缘计算平台能不能被团队真正用起来的关键因素。一个边缘函数写出来很容易但调试一个在边缘节点上运行时才出现的 bug如果没有好的工具会非常痛苦。Cloudflare Workers 的本地开发工具是wrangler dev。它在本地启动一个模拟边缘环境的开发服务器支持热重载、断点调试通过--inspect和console.log输出。它还提供了一个「远程调试」功能你可以把本地开发的代码临时部署到一个远程 Worker用真实环境测试而不需要完成一次完整的发布。这个功能在调试「只有生产环境才出现的问题」时非常有用。Vercel Edge Functions 的本地开发体验更「集成」——如果你用的是 Next.js直接next dev就能本地运行边缘函数不需要额外工具。Vercel also providesvercel dev用于在本地模拟 Vercel 的部署环境。调试方面Vercel 的 Edge Functions 日志会实时出现在 Vercel Dashboard 里也可以在本地通过console.log输出。部署体验方面两个平台都做到了「git push 即部署」。Cloudflare Workers 需要配置wrangler.toml或者通过 Cloudflare Dashboard 配置 CIVercel Edge Functions 只需要把代码推到 GitHubVercel 自动检测 Next.js 项目里的边缘函数并部署。对于已经用 Vercel 部署前端项目的团队Edge Functions 的部署体验是零额外的。但需要注意的是边缘函数的「部署」和「生效」之间可能有延迟。Cloudflare Workers 的全球传播通常在一两分钟内完成Vercel Edge Functions 的传播延迟类似。在部署关键修复时这个延迟虽然短但也需要考虑。四、性能与限制冷启动、执行时长与请求限制边缘计算平台通常有一系列限制这些限制直接影响你的代码能做什么、不能做什么。冷启动时间Cloudflare Workers 的冷启动时间在毫秒级通常用户感知不到Vercel Edge Functions 的冷启动时间也类似。这是因为边缘函数不是「启动一个 Node.js 进程」而是「在一个已经运行的 V8 Isolate 里执行代码」开销极小。执行时长限制Cloudflare Workers 的 CPU 时间限制是 10ms免费计划到 30ms付费计划每次请求——注意是 CPU 时间不是墙钟时间。如果你的代码里有一个fetch请求等待响应的时间不计入 CPU 时间但如果你有一段计算密集的循环它可能在几毫秒内就耗尽了 CPU 配额。Vercel Edge Functions 的执行时长限制是 30 秒墙钟时间比 Cloudflare 宽松但建议仍然保持函数在几百毫秒内完成。请求体大小限制Cloudflare Workers 的请求体大小限制是 100MB付费计划Vercel Edge Functions 的限制是 4.5MB。如果你的边缘函数需要处理文件上传这个限制会直接影响方案选择。这些限制的存在意味着边缘计算不是「把所有后端逻辑都搬去边缘」。边缘适合做「轻量的、延迟敏感的」逻辑API 路由、请求改写、A/B 测试、鉴权、缓存策略。重计算、大文件处理、长时间运行的任务仍然适合放在中心服务器或者 Serverless 函数里。五、总结边缘计算与 CDN 选型是在延迟、运行时约束、开发体验和成本之间做权衡。Cloudflare Workers 适合需要通用边缘计算能力的场景它的运行时标准、全球节点多、计费模式灵活Vercel Edge Functions 适合已经用 Next.js 和 Vercel 的团队它的集成体验无缝、调试方便、部署零配置。无论选哪个边缘函数的设计都应该遵循「轻量、无状态、快速失败」的原则让边缘真正成为性能的助力而不是复杂度的来源。