接 API 时遇到「429 Too Many Requests」报错？这是平台限流机制在起作用！分享 4 个实战技巧，既能避免限流，又能保证高并发场景下的调用效率：
精准控制调用频率，贴合平台规则首先在 API 文档中查询限流阈值（常见：每秒 1-5 次、每天 10 万次），按阈值设置调用间隔：
单线程场景：用时间.sleep () 控制间隔（如每秒 5 次 = 间隔 0.2 秒）； 多线程场景：用信号量（Semaphore）限制并发数（如 Python 的 threading.Semaphore (5)）；示例（Python）： python
运行
import time import requests
def call_api(url, params): time.sleep(0.2) # 间隔0.2秒，适配每秒5次限流 return requests.get(url, params=params) AI写代码 使用缓存机制，减少重复请求对非实时数据（如商品分类、快递公司列表），本地缓存结果，有效期内不再调用 API：
缓存工具：Redis（推荐，支持过期时间）、本地文件； 缓存策略：设置合理过期时间（如分类数据 1 小时过期，商品详情 30 分钟过期）；示例逻辑： plaintext
if 缓存中存在该商品数据且未过期： 直接返回缓存数据 else： 调用API获取数据，存入缓存，设置过期时间 AI写代码 批量接口替代单次接口，减少调用次数优先使用平台提供的批量接口（如 batch_item_get = 批量获取商品详情），一次请求获取多条数据：
对比：单次接口需调用 100 次获取 100 个商品，批量接口 1 次即可； 注意：批量接口有参数限制（如最多 50 条 / 次），按限制拆分请求。 失败重试 + 错峰调用，提升稳定性
重试机制：限流报错后不要立即重试，用「指数退避法」（第一次间隔 1 秒，第二次 2 秒，最多 3 次）； 错峰调用：大促期间（如 618、双 11）避开平台高峰时段（9:00-12:00、20:00-22:00），选择凌晨或清晨处理批量任务。 补充：如果业务需要突破限流阈值，可联系 API 平台申请提升额度（需提供业务证明）。你们在高并发场景下，有没有遇到过棘手的限流问题？评论区交流～
编辑摘要 API 调用遇到 429 限流报错？4 个实战解决方案：精准控制调用频率、本地缓存减少请求、批量接口替代单次、失败重试 + 错峰调用，附 Python 示例代码，适配高并发场景，保证 API 稳定调用不中断～
