如何使用 Vercel Workflows 在无需外部队列的情况下实现支付逻辑

面向生产环境的步骤分离

在使用 Serverless 函数时，经常会遇到执行时间限制的瓶颈。Vercel Workflows 为了解决这一问题，将异步函数转换为可维持状态的进程。这里的核心在于：必须消除编排器（Orchestrator）函数中诸如数据库写入或随机函数等不确定因素。所有的副作用都必须封装在 step.run 代码块中，以防止系统逻辑出现偏差。

在控制整体逻辑的函数中声明 use workflow，并仅负责流程管理。将实际的 API 调用或数据库操作定义为独立的步骤（Step）。在进入下一步时，应只传递必要的数据，这样可以节省日志存储成本。通过这种架构，即使中间任务失败，也不必从头开始，只需从停止的点恢复即可。

防止重复支付的幂等逻辑

在分布式系统中，由于网络错误，同一个步骤可能会执行两次。这在支付系统中简直是灾难。Vercel Workflows 为每个阶段提供唯一的 stepId。在集成 Toss Payments 或 Stripe 时，将此 ID 用作幂等键（Idempotency Key），即可有效防止重复支付事故。

请在代码中加入“写入数据前检查是否已处理”的模式。可以通过 getStepMetadata() 提取 ID 并将其分配给外部服务请求的 Header。如果该事务已处理，应设计为立即返回。只要构建好这一结构，就能减少不必要的 API 调用，从而节省 20% 以上的基础设施成本。

无超时限制的长期任务管理

Vercel 的 Serverless 函数通常在 1 到 15 分钟内就会关闭。但如果使用 step.sleep，即使是耗时数日的预定任务也能轻松应对。执行此函数时，工作流状态会被记录到存储中，函数则立即结束。在等待期间，不会产生计算费用。

例如，如果需要在支付完成 3 天后发送调查问卷邮件，只需一行 await step.sleep('3 days') 即可。由于无需管理额外的 Crontab 或调度程序，每周可减少约 2 小时的运营时间，同时也消除了 24 小时运行服务器的成本。

在本地验证工作流

反复部署和修改会降低开发速度。利用 Vercel CLI 的功能，无需上传到云端即可在本地进行测试。如果需要接收外部 Webhook，可以使用 ngrok 等工具将本地主机暴露给外部。

运行 vercel dev 并将 ngrok 生成的 URL 注册到 Stripe 的 Webhook 设置中，本地代码即可实时接收外部事件。这让你能在部署前预先验证失败场景，开发速度可提升 2 倍，同时也减少了因环境变量配置错误而浪费的时间。

基于指数退避的重试策略

由于 API 速率限制或临时网络故障导致的无限重试会造成费用爆炸。必须根据错误的性质采取不同的应对措施。对于认证失败等永久性错误应立即停止，而对于网络故障等临时性问题，则应间隔一段时间后重试。

请应用逐渐增加重试间隔的指数退避（Exponential Backoff）公式：

$$Interval = InitialDelay \times 2^{Attempt}$$

在 step.run 函数中设置 maxRetries: 3 以限制最大重试次数。系统会自动恢复，从而提高服务可用性，并预先拦截因无限循环导致的过度计费。

运营成本与基础设施效率

以 Pro 方案为准，Vercel Workflows 默认提供 50,000 次步骤执行。超出部分按每 100,000 步 $2.50 的标准收费。长期等待时产生的存储费用仅为每 GB-Hour $0.00069，非常低廉。

分类	Hobby/Pro 包含量	超出费率
Workflow Steps	50,000 步	每 100,000 步 $2.50
Workflow Storage	720 GB-Hours	每 GB-Hour $0.00069
Serverless Function	1,000 GB-Hours	每 GB-Hour $0.60

与亲自构建和管理复杂的消息队列相比，这具有压倒性的经济性。只要将幂等性保证与指数退避正确结合，就能在没有基础设施管理负担的情况下，确保生产级别的可靠性。对于想要专注于业务逻辑的独立开发者来说，没有比这更合理的选择了。