社交媒体 API 速率限制：需要规划哪些方面

通过 API 发布内容时，速率限制存在于两个层面，而人们常常忘记的是平台那一层。这里介绍如何针对这两者进行设计。

如果你以编程方式发布内容，会有两种独立的速率限制生效，而其中只有一种在你的掌控之中。

两个层面

平台的限制。 每个社交网络都会限制任何一个应用能在其 API 上做多少操作，各自有自己的时间窗口、自己的响应头，以及超限时各自的行为。这些在不同平台之间各不相同，而且改动前通常不会提前太多通知。

你的服务商的限制。 如果你通过一个统一 API 发布内容，这个服务本身也有一个限制，通常和你的套餐挂钩。

第二种很容易看清楚，也容易据此规划。第一种才是真正会咬人的那一种，因为如果你用的是统一 API，你根本看不到它。服务商替你吸收了这部分，这也是你付费购买的价值中很大一部分，但它并不会因此消失：一个平台在限流所有人，仍然意味着你的帖子被延迟了。

发布管道里最常见的错误，是把”已接受”当成”已发布”。

在好几个平台上，提交一条帖子会返回成功，而实际的发布过程发生在之后。所以失败会在之后才到来，脱离你原本的请求流程，远在你的请求已经返回 200 之后很久。如果你的数据模型只有”已发送”和”失败”两种状态，就没有地方能放下”我们认为它正在发布中”这种状态。

要为三种状态做设计，并让”待定”这个状态可见。

指数退避。 遇到 429，要等待一段时间再重试，且延迟递增。立即重试只会让情况更糟，还可能延长限流时间。

给重试设上限。 一个无限重试的管道，会在几分钟内把配额耗光。该放弃时就放弃，大声记录日志，让人来看一眼。

绝不要盲目重试一次创建请求。 如果一次创建请求超时了，你并不知道它到底有没有成功。重试可能会产生重复的帖子，这比原本的失败更糟糕。重试前先核对一下，或者用一种能让重试变得安全的方式。

在接口支持的地方使用批量操作。 一个请求创建多条帖子，只消耗一次请求。同样的工作量用五十次单独调用来做，就要消耗五十次请求。

免费套餐每天 30 次请求的额度，是刻意设定来用于评估这个 API，以及运行一些轻量的个人用途的。它不足以支撑一条真正的生产管道，而一个没有退避机制的循环几秒钟就能把它耗尽。

需要注意，API 请求数和帖子数是两个独立的限制。列出频道、检查状态和上传媒体都会消耗请求次数，但不会创建帖子，所以只有在你使用得当的情况下，请求预算才会比帖子数量所暗示的更经用。

付费套餐包含多个 API key，原因并不是为了获得更高的吞吐量。而是为了让不同的东西持有不同的凭证：你的生产管道、一个预发布环境、一个 AI 智能体。

它的价值会在出问题的时候体现出来。你可以在凌晨两点撤销某一个 key，而不用去轮换所有东西共用的那一个凭证。

有两种限制在起作用：平台的限制，你透过统一 API 是看不见的；以及你服务商的限制，这个你能看见。要指数退避、给重试设上限、绝不盲目重试一次创建请求、能批量就批量。并且把”已接受”当作一个与”已发布”截然不同的状态来对待，因为在好几个平台上，它确实就是这样。