生成接口重试如何避免重复扣额度

任何调用耗时较长服务的 Web 操作，都必须处理一种常见故障：服务器可能已经完成了工作，但响应却在浏览器收到之前丢失了。

如果用户重试，而后端把这次重试当成新的操作，同一个请求就可能消耗两次配额，或生成重复的输出。按钮只被点击一次，并不代表只有一个请求到达服务器。

一种实用的设计模式是：为每次预期执行的操作分配一个稳定的幂等键（idempotency key）。服务器在开始执行高成本任务之前，先记录这个键。再次收到携带相同键的请求时，服务器返回已有操作的状态，而不是启动另一次操作。

一种可行的状态模型如下：

reserved -> completed
         -> failed

配额预留应限定到具体用户和具体操作。还可以使用一个独立的操作 ID，让客户端在超时后查询状态。这样，UI 就能根据服务器记录的状态，显示“仍在处理中”“已完成”或“失败”，而不是根据按钮点击情况猜测结果。

棘手的情况是上游超时。超时并不一定意味着服务提供方没有执行任何工作。在释放预留配额或向服务提供方发起新请求之前，应先检查能否查到原来的操作，或者能否使用相同的幂等键安全重试。否则，一次超时就可能导致重复执行。

这是一种设计模式，并不是在描述任何特定产品的实现。合适的配额规则取决于产品对用户的承诺：失败的尝试是否计费、处理中的任务是否预占容量，以及一次操作最多可以保持多久的未决状态。先明确这些选择，再测试并发启动、浏览器重试、服务提供方超时和响应延迟等情况。

我是 Prem，Zextha 的创始人。本文在 AI 辅助下完成。

如需采取进一步措施，你可以考虑屏蔽此人和／或举报滥用行为。