日志里飘着超限报错，接口却还在正常返回结果，这种自相矛盾的情况很容易让人误判：有人以为额度还有富余继续加压，有人以为服务坏了直接换站。这篇按「先分清是哪种超限」的思路，把提示语、响应码和实际返回结果对照着看，给一套能照着走的排查顺序，再讲怎么从并发、退避和配比上把这类问题压下去。
日志里飘着超限报错，接口却还在正常返回结果，这种自相矛盾的情况很容易让人误判：有人以为额度还有富余继续加压，有人以为服务坏了直接换站。先别急着下结论，绝大多数这类现象都不是链路坏了，而是你看到的「超限」和实际拦下请求的那道限制不是同一回事。
这篇按「先分清是哪种超限」的思路，把提示语、响应码和实际返回结果对照着看，给一套能照着走的排查顺序，再讲怎么从并发、退避和配比上把这类问题压下去。全程不需要你猜平台的阈值，靠响应里的信息和本地日志就能定位到大半。
先搞清楚「超限了还能用」是哪种超限
同样是报超限，背后可能是三种完全不同的限制在起作用，混在一起看就会觉得自相矛盾。先把提示语归类，后面的排查才不会白做。
- 固定窗口计数
- 按分钟或按天算次数，窗口一过就恢复，表现为时好时坏、偶尔报错
- 并发槽位占满
- 同一时刻在途请求太多被挡，单发能过、批量就报
- 配额或余额类
- 账户层面的总量或剩余额度受限，与请求节奏无关，通常持续报
- 典型现象是部分请求返回超限提示、部分正常返回，说明挡的只是某一时刻的窗口或槽位，不是整条链路
- 还有一种常见情况：响应体里带了错误字段，但流式内容其实已经推完，客户端要看 finish 状态而不是只看有没有内容
- 同一 Key 在多个客户端或多人共用时，计数是共享的，你自己觉得没超并不代表总账没超
- 反过来，如果所有请求都超限且零返回，那不属于本文场景，应先按鉴权和余额方向查，别在并发上折腾
排查顺序：从响应头和日志开始，别凭感觉
排查建议固定成四步，从外到内，每一步都有明确的判据，不要一上来就改代码。顺序乱了很容易把限流问题和客户端 bug 搅在一起。
- 对照状态码与返回体先看 HTTP 状态码和实际返回内容是否一致。不少中转会把上游错误塞进一个正常状态码的响应体里，这时你的 SDK 不会抛异常，只会拿到一段错误 JSON，得自己解析业务字段来判断。
- 翻响应头和控制台用量找剩余次数、重置时间、重试等待这类字段，有就按它算下一次安全发送时间。没有的话去平台控制台的用量页看计数曲线，曲线和日志对不上就说明限制口径不是按请求数算的。
- 本地日志按时间戳对齐把报错请求和成功请求按毫秒时间戳排一遍，看它们是不是挤在同一秒的窗口里。如果成功请求总是紧挨着报错请求，基本可以确认是窗口或并发槽的问题，而不是额度没了。
- 做最小复现单线程串行发几条，间隔拉开。如果照样报超限，问题在账户或配额层；如果一切正常，问题就在并发和重试策略上。这一步做完，方向基本就定了。
拿不准某个厂商的限速口径时，别靠猜，到 /official-api 核对对应厂商的限速说明，看清楚是按请求数、按 token 还是按并发算的，这三种的重置逻辑完全不同。
| 观察到的现象 | 更可能的原因 | 下一步动作 |
|---|---|---|
| 报错与成功交替出现 | 窗口计数或并发槽位 | 加并发闸门，配退避 |
| 流式响应已出内容却报错 | 中途限流或上游截断 | 记录 finish 状态，不整条重发 |
| 单发正常、批量必报 | 并发超过槽位上限 | 限制在途请求数，分批跑 |
| 持续报错且无任何返回 | 配额、余额或鉴权 | 先查账户与 Key 状态 |
规避方案：把请求摊开，而不是加大重试
很多人遇到超限的第一反应是把重试次数调高、把超时调长，结果队列越堆越深，超限反而更频繁。正确方向是把压力摊开，而不是在堵点上加压。
- 给客户端加并发闸门，同一 Key 同时在途的请求数控制在一个明确上限，超出的排队而不是直接发
- 指数退避加随机抖动，并设置最大重试次数，避免超限那一瞬间形成重试风暴
- 把批量任务按 Key 或分时段拆开，削掉突发的尖峰，比事后补救省事得多
- 流式请求单独判断：已经开始输出内容的请求不要整条重发，否则会重复计费，只补没出完的部分
- 把每次超限的响应头和重试时间写进日志，下次调参有依据，不用凭记忆
接口延迟基线不清楚时，先到 /tools/speed-test 量一遍实际往返时间，再据此定超时和重试参数。基线不准，退避间隔要么太短没效果，要么太长拖慢整体吞吐。
什么情况下该换站或换方案
不是一超限就该换站，也不是所有站都值得继续扛。判断的关键是：这个限流口径你能不能看见、能不能预测。
| 情况 | 判断 | 建议 |
|---|---|---|
| 偶发超限，有明确重置时间 | 正常限流 | 按重置时间调度，不用换 |
| 日常用量下频繁超限 | 档位与并发不匹配 | 先看是否可升档或拆 Key，再谈换 |
| 长期无剩余量信息、报错与成功混杂 | 限流口径不透明 | 长期跑业务要慎重 |
| 换了 Key 仍持续超限 | 账户或配额层 | 回到账户侧排查 |
选型时把「限流是否可查、有没有明确的重置时间」当成一项和价格并列的硬指标。便宜但限流不可预测的通道，在批量业务里带来的维护成本往往更高，这笔账要算进去。反过来，如果你只是偶尔手动调用，限流口径粗一点影响不大，不必过度纠结。
- 先看检测结论，到 /rankings 翻中转站的可信度与稳定性记录
- 再看具体站点说明，到 /sites/all 找该站的限流与配额描述
- 价格类数字不要凭印象，到 /price-watch 核对当时的口径
- 比价时把限流透明度、重置时间一起列进对照表，而不是只看单价
常见问题
报超限但请求确实成功了，这笔调用还会计费吗？
只要有正常返回内容就会计费，提示语本身不抵扣。所以别把超限报错当成免费窗口反复试探，正确做法是限流后降速，而不是靠重试刷成功。想估算成本可以到 /tools/model-cost-calculator 按实际调用量算一遍。
同一个 Key，我这边没超，同事那边一直报超限，为什么？
多半是并发额度或窗口计数被共享了。先确认是不是多人共用一把 Key，再让对方在他那边单独复现一次。如果是共享，最省事的做法是按人或按任务拆 Key，各自盯自己的用量。
要不要给客户端加大重试次数来「抢」成功？
不建议。超限场景下加次数只会放大瞬时压力，反而让限流窗口一直被你占满。更稳的是限并发加退避，把重试次数控制在小范围，并给整批任务留出可接受的总耗时。
