后台的采集任务凌晨开始跑，前十篇正常，之后全是同一个报错。接口返回429，响应体里写着rate_limit_exceeded。白天手动点几下都不报，脚本一跑起来就成片地红。脚本里循环三千次，前一百次顺畅，之后每次都要重试，任务卡在那里一动不动。很多人到这里就去翻代码，怀疑并发写错了。429这个状态码的意思是请求太多了，服务端把门关上了，跟代码逻辑没关系。它只管限速，不管对错。这类报错半夜把人叫起来，第一反应是翻代码，翻两小时才发现是额度。
限流通常有两个维度，一个是每分钟请求数，一个是每分钟token数。前者容易理解，后者最容易被忽略。一段三千字的中文提示词，token数大约四千上下，一次请求就抵掉几十次空请求的额度。请求数明明只有个位数，额度照样被打满，报的还是429。按次计费的账户看前者，按量计费的多半栽在后者。
响应头里有三条数最有用，剩下的额度、重置时间、配额上限。每次报错把这三条记进日志，比事后猜有用得多。x-ratelimit-remaining-requests到零，就是请求数这条线先断的。剩得还很多却报429，去看token那条。
有一种429重试一百次也没用，响应体里的code是insufficient_quota。这不是限速，是账户余额或者额度周期用完了。脚本无脑重试，只会把日志刷满，账单一点不动。区分办法很简单，看code字段，别看状态码。限速的那一类，等一会儿会自己好；配额的那一类，等到天亮也不会好。
重试逻辑写错会把小事放大。你的循环里，失败就立刻重试，三次不行再来三次，一秒内十几个请求打出去，本来只超了一点点的额度，直接顶到上限。加重试是对的，前提是带退避，第二次等两秒，第三次等四秒，再加一点随机抖动。响应头里给了retry-after就照着等，比自己拍一个数准。另一类更隐蔽，站点起了四个worker，每个worker各自限流，单看谁都没超，加起来早就超了。
把日志按分钟聚合，429是不是成簇出现，一眼就能看出来。均匀散布是额度本身不够，成簇就是重试没退避。两种改法完全不同，改错了方向等于白折腾一晚。
现在这套脚本是本地令牌桶加指数退避，桶容量按账户额度的七成设。留三成余量，是为了让后台的实时请求还有得用。提示词也顺手瘦了，把每次都重复的大段背景挪到系统消息里，靠缓存命中省钱又省额度。跑了一周，429从每天两百多次降到个位数。剩下那几次是额度周期切换时的正常抖动。
申请创业报道，分享创业好点子。点击此处，共同探讨创业新机遇！
