Cloudflare Workers还是Vercel：冷请求速度与迁移成本

已有较完整的 Next.js 应用，尤其依赖 Node.js 包时，Vercel Functions 通常能减少迁移工作；轻量 API 则值得评估 Cloudflare Workers。一组从新加坡发起的公开补测记录显示，经过代码适配的 Workers 部署，冷状态整次请求约耗时 700—950 毫秒，Vercel Serverless 部署约为 1089 毫秒。

速度差有参考价值，迁移代价也真实存在：补测中的 Workers 版本注释掉了部分不兼容的 Node.js API。对需要访问数据库的项目，函数响应还取决于数据所在区域和往返次数。选择平台时，应同时比较完整请求的延迟、账单单位，以及现有代码在目标运行时能否工作。

新加坡补测：快的是整次冷请求

补测使用部署在多个平台上的 Next.js 页面和 API 端点，从新加坡在隔夜闲置后发起并发请求，并跨两天重复。记录者测量的是整次请求耗时，数字包含网络传输与应用处理，不能直接当作运行时自身的启动时间。比较对象中的 Vercel 部署是 Serverless Functions；换用 Vercel Edge Runtime，不能沿用这组结果。

端点相近不等于运行的代码完全相同。Workers 版本删改了 Node.js API，记录者认为这可能缩小打包产物、减少执行工作；这是一种可能的影响，并未被单独量化。因此，这组数据能说明该测试配置下用户可见的冷请求速度，却不足以保证把现有 Next.js 应用迁过去也会得到同样差距。

它还把一个容易漏掉的成本摆在了速度旁边：为了让代码运行，开发者先做了适配。若项目请求主要在入口完成校验、转换或路由，较近的执行位置可能更有价值；若一次请求要反复访问远处数据库，入口节省的时间可能被后续网络往返吃掉。后者是由请求路径推导出的选型判断，并非补测给出的通用性能结论。

把请求耗时和账单单位放在一起

两边的价格数字不能直接按“每百万次”相减。Cloudflare 的Workers 定价表列明，付费方案账户最低每月 5 美元，包含每月 1000 万次请求和 3000 万 CPU 毫秒；超额部分分别按每百万次请求 0.30 美元、每百万 CPU 毫秒 0.02 美元计费，Workers 不另收数据传出或吞吐带宽费。该表也将静态资源请求与执行 Worker 的请求区分开来。

Vercel 的函数调用计费公告给出 Pro 方案每次调用 0.0000006 美元，按调用量换算为每百万次 0.60 美元。它描述的是函数调用这一项，不能代表整个 Next.js 项目的总费用。比较时还要纳入各方案的包含额度，以及项目实际使用的计算、数据传输、图片处理和存储服务。

一个条件示例能说明差别：两个 API 即使收到相同数量的请求，只要其中一个需要更多计算，Workers 的 CPU 用量就会不同。等待外部接口或数据库响应所经过的时间，也不应直接当作 CPU 执行时间。反过来，Workers 没有单独的带宽费，并不表示与它配合使用的所有数据产品都没有费用。先分清哪些流量真正执行函数，再估算两套账单，比只盯着调用单价可靠。

Next.js 的迁移工作落在哪里

对于已有 Node.js 服务端代码，Vercel 的主要便利是运行时连续性。其Node.js 运行时文档说明，使用该运行时的 Vercel Functions 可访问完整的 Node.js API。这降低了因更换运行时而修改依赖的可能性，但项目是否能顺利部署，仍取决于实际构建配置和使用的包。

Cloudflare 也提供 Next.js 部署路径，不过迁移时需要核对框架与依赖的兼容性。Cloudflare 的Next.js 部署指南推荐使用仍处于 beta 阶段的 vinext，并建议现有生产应用先运行兼容性检查；已有 OpenNext 应用仍有相应的部署路径。指南列出 Route Handlers、Server Actions 等支持情况，同时将图片优化标为部分支持，说明“可以部署 Next.js”不能替代逐项核对。

迁移工作通常藏在服务端路径里：认证、依赖包、路由处理、缓存和图片请求可能各自使用不同能力。构建成功只说明代码进入了部署产物，不能保证某个依赖在实际请求中调用的 API 也按预期工作。对现有应用，较有意义的比较对象是同一条业务请求在两边的执行结果，以及为使这条请求正常运行所做的代码改动。

三类项目怎样选择

已有完整 Next.js 应用：如果服务端使用较多 Node.js 包，且当前部署方式满足延迟与费用要求，优先保留 Vercel Functions 通常更省迁移工作。只有关键请求的收益足以覆盖兼容性改造，转向 Workers 才更有理由。
轻量 API：如果接口主要做请求校验、简单转换或路由，且较少依赖 Node.js 特有 API，Workers 值得优先试用。估算成本时同时记录请求数与 CPU 消耗；函数调用单价本身不足以决定哪边便宜。
面向多地用户的低延迟服务：先看用户、函数和数据源的相对位置。若请求大部分工作可在靠近用户的位置完成，Workers 的冷请求结果提供了评估理由；若每次请求仍要多次返回单一区域取数，应以包含数据库往返的完整响应时间作判断。

对需要作出迁移决定的团队，最有价值的比较是同一条真实请求：带上项目现有的认证、依赖和数据读取，记录冷状态与连续请求的耗时，并列出两边为成功部署所需的改动。这样，较快的响应、每月费用和迁移工时才对应同一个业务负载。