工具笔记
让 AI 写限流重试：429 的等待时间怎么验
限制尝试次数，并区分能安全重试的请求。
资料核验2026.11.12 · HTTP 与 Fetch · 浏览器及服务端请求
一个抓取任务遇到 429 后马上重试，日志转眼堆满同一条请求。429 表示请求过多，服务端可能带 Retry-After 告诉客户端等多久。
给 AI 的上下文与边界
给助手一个本地抓取服务，依次返回 Retry-After 秒数、HTTP 日期、无效值和正常结果。要求它注入可控制的时钟或等待函数，验证调度逻辑，限制尝试次数和整轮时间。
把等待规则写成可验收的行为
处理 Retry-After 的两种形式，秒数和 HTTP 日期。缺失或无效时采用有限退避，设置整体时间预算，超出就安排下一轮。不要无条件重试可能重复写入的请求。
用本地响应依次返回带等待提示的 429 和正常结果。记录两次请求的间隔以及上限到了是否正确停止。
若几个 worker 共用同一上游配额，应在它们之间协调速率。单个 worker 放慢，未必能让总量降下来。
可以直接照着做的演练
让本地服务先返回 429 Retry-After: 3，时钟前进三秒才允许下一次请求。再测试 HTTP 日期和超过总预算的延迟。不要用单测真的睡很多秒，可让等待函数记录计划值。
检查生成结果
- 秒数和 HTTP 日期都能转换。
- 超过本轮预算时停止。
- 无效值采用有限退避。
- 对于可能重复写入的操作按业务幂等性另行判断。
复查时追问一层
审核时记录实际触发的请求次数和计划时间。多个 worker 共用同一配额时，单个 worker 的重试正确仍可能让总量过高。若有共享速率控制，测试应同时跑两个 worker。
若上游的等待日期已经过去或格式不可读，要有稳定处理。不要让定时器接受负值而形成紧密循环。把时间解析、重试次数与请求安全性分别写成可验收的规则，报告实际调用次数而非只给最终 200。
