百度API免费调用次数限制

很多人接百度系接口时，第一反应是「免费额度还有多少」，但真正卡住你的往往不是总量，而是按天重置、按 QPS（每秒查询数）卡、按单个应用或单个接口算这三套口径叠在一起。这篇不背具体数字，只讲清额度怎么算、超限时接口长什么样、以及工程上该在哪里加缓冲。

很多人接百度系接口时，第一反应是「免费额度还剩多少」。但真正把任务卡住的，往往不是总量被用完，而是三套口径叠在一起：按自然周期的总量、按秒或分钟的瞬时速率、按单个应用或单个接口单独计数。任意一维触顶，请求都会失败。所以先别只盯总数，先搞清楚你踩的是哪一维。

这篇不背任何具体数字，只讲清额度按什么算、超限时接口长什么样、代码里该在哪几处加缓冲。真要看当下的额度档位和计费口径，去站内对应页面核对，那里才是会随平台调整而更新的地方。

免费额度到底按哪几个维度算

百度各开放平台的免费额度，通常不是「一个池子用完就没」。常见是三套口径叠加计算，任一维触顶都会失败。规划用量时要把三套都算进去，只按月度总量估，很容易在高峰期被瞬时速率拦住。

• 额度重置时间点通常跟控制台里那个应用的创建时区有关，别默认是本地零点，跨天跑批任务要按平台口径留缓冲。
• 免费额度往往绑在具体接口或具体模型上，同一个应用下不同接口的可用量不一定互通，别按一个池子去规划。
• 同一个接口的不同能力档位，也可能各算各的次数，调参前先确认你走的是哪一档。
• 不适用的情况：如果你走的是中转站或第三方聚合通道，额度口径由通道方决定，这三套判断不适用，要去通道后台看它自己的规则。

超限时接口会怎么回你，先分清是哪一类

超限不是一种错，是好几类。把它们混在一起排查，最容易浪费时间。返回体的错误码和提示语是第一手线索，响应耗时是第二手，网络是最后才该怀疑的。

鉴权或权限类

提示应用未开通该接口，跟次数无关，先回控制台核对开通状态。

明确限流类

返回体带重试建议，说明瞬时限速被打满，降并发比继续重试更有效。

余额或额度耗尽

请求根本没进模型，日志里看不出耗时异常，容易被误判成网络问题。

网络类

表现为超时、连接重置，与额度无关，但对日志来说长得和超限很像。

1. 第一步 看返回体先读错误码与提示语，判断属于上面哪一类，别跳过这一步直接去查代理。
2. 第二步 看耗时额度耗尽型请求往往秒回，网络型会拖到超时阈值；两者耗时特征不同，能帮你快速排除。
3. 第三步 看范围是单个接口全挂，还是整个应用全挂，还是个别的几台机器挂；范围决定了是配额问题还是部署问题。
4. 第四步 再查网络前三步都排除后再查链路，否则容易把配额问题当成网络故障反复折腾。

代码里该在哪几处加缓冲

缓冲不是出事后再补，是在几个固定位置提前埋好。核心思路是：把超限当成可预期的正常状态，而不是异常。这样任务链不会因为一次限流就整体中断。

• 入口处做一层本地计数与配额台账，别依赖事后看控制台；跨进程任务要落到共享存储上，否则每个实例都以为自己还有余量。
• 给每个接口设独立的并发上限与排队队列，而不是全局一个值，避免一个慢接口把配额吃干净。
• 把超限当可预期状态捕获，进入退避重试或切备用通道，别让整个任务链中断。
• 日志里固定记清应用、接口、时间戳三个字段，事后复盘是哪一维打满才有的查。
• 给重试设上限和最长等待，避免限流时无限重试把下游也拖垮。

# 伪代码示意：入口处先过一层本地配额检查\n# 1. 读共享存储里的当日计数与当前并发数\n# 2. 超过阈值直接进队列，不发请求\n# 3. 捕获限流返回体，指数退避后再试\n# 4. 失败次数达上限，切备用通道或标记任务待重跑

额度不够时的降级与替代路子

额度紧张时，先想降级，再想换源。降级通常改动小、当天就能上线；换源要动配置、动解析、动测试，时间和风险都更高。

确实要用量更大，可以对比官方按量档位与各家聚合通道的计费口径。具体数字会随时间调整，到站内官方入口页和模型平台导航页核对当时的数字，别拿旧截图做决策。做多通道备份时，要确认返回结构是否一致，否则降级代码得写两套解析逻辑，维护成本会翻倍。

怎么持续盯住额度，而不是出事才发现

额度这件事，出事才看就晚了。要把它做成日常指标，按周期记录，看环比变化而不是绝对值。突增往往比数字本身更值得关注，因为突增通常对应代码改动或上游调用异常。

• 按天记录额度消耗，做环比曲线，突增当天就要查是哪段代码在放大调用。
• 给关键接口设阈值告警，留出至少一个完整批次的余量，别等到归零才提醒。
• 上线前用接口测速工具量一遍延迟基线，超限与慢请求表象很像，有基线才分得清。
• 把额度检查放进发布清单，任何改动调用量的上线都要先过一遍。