速率限制

服务商设置限制，理由很朴素。容量是有限的，而且是共享的，所以一个失控的脚本不应该拖慢其他所有人。限制还能控制成本，阻止滥用，比如有人拿被盗的密钥去冲击服务。没有它们，循环里的一个缺陷，就可能在一分钟内发出成千上万次调用。想象一家为排队顾客服务的面包店：让一位顾客在第一分钟就买走所有的面包，对其余的人不公平，所以面包师给每个人设一个上限，而一个好的限制，不过是写成数字的公平份额。

限制有几种形式。每分钟的短期限制用来吸收突发的流量。更长的限制，比如按天，约束总使用量，它可以是在固定时刻重置的固定窗口，也可以是始终回看最近一段时间的滚动窗口。有些服务统计请求数，有些统计 token 数，还有些会限制同一时刻可以并行的调用数。限制通常取决于套餐，所以更高的档位有更高的上限。

妥善应对限制是一门小手艺。有 Retry-After 头时就读取它，并等待相应的时间。否则就用指数退避加上少量随机抖动来重试，绝不要在紧凑的循环里重试。通过缓存答案、批量处理来减少调用次数，并把负载分散到不同的时间。要记住，速率限制不是消费限额：余额用完是另一个错误，解决办法也不同。库通常会为你包装这套逻辑，礼貌地重试并在两次尝试之间暂停；如果你自己编写客户端，请把每个 429 连同时间戳一起记录下来，这样你就能看出，是突发流量还是持续的负载引起了它。

NeverNo 的 API 文档规定了规则。每个账户在滚动的 24 小时内有一定数量的 API 请求，数量取决于其套餐。超过之后，调用会收到带有代码 rate_limited 的 429，直到窗口移动。每分钟的短期限制同样适用，此时 429 会附带 Retry-After 头。无论 token 或图片的数量多少，每次调用都算作一次请求，而统计 token 的端点不计入。因为窗口是滚动的，容量会随着旧的调用逐渐过期而慢慢恢复，而不是在午夜一下子全部恢复。

各方案的具体数字在 API 文档的表格里，我们不在这里重复，以免这一页变得过时。积分用完是另一种情况：API 会返回 402，并带有 insufficient_credits。Dev 订阅使用 Pro+ 的请求限制。因为文档是这些数字的唯一出处，脚本应当从那里读取上限，而不是写死一个猜测，并把 429 错误的突然增多视为需要放慢速度、让工作排队的信号。