API限频是交易所对单位时间内请求次数设定的硬性上限，超限即触发拒绝响应或延迟处理，直接导致策略信号无法及时送达撮合引擎。
Binance币安
欧易OKX ️
Huobi火币️
gateio芝麻
API限频是交易所对单位时间内请求次数设定的硬性上限，超限即触发拒绝响应或延迟处理。它直接导致策略信号无法及时送达撮合引擎。
一、API限频的本质与触发机制
限频并非随机限制，而是由交易所网关依据IP+密钥组合实时统计请求频次，并与预设阈值比对后执行拦截。每次HTTP状态码429或gRPC StatusCode.ResourceExhausted即为明确信号。
1、打开交易所API文档，定位“Rate Limits”章节，确认当前密钥等级对应的每分钟/每秒请求配额。
2、在策略日志中搜索关键字“429”或“ResourceExhausted”，统计单位时间内的错误出现密度。
3、使用curl命令模拟高频请求：curl -I -H "X-MBX-APIKEY: YOUR_KEY" https://api.binance.com/api/v3/time，观察响应头中的X-MBX-USED-WEIGHT字段变化。
二、本地请求队列溢出导致指令堆积
当策略逻辑未做异步节流，多个模块（行情监听、信号计算、下单执行）并发调用同一API实例时，请求在内存队列中排队，造成指令发出时间严重偏移。
1、检查代码中是否对所有API调用统一复用单个HttpClient实例且未设置最大并发连接数。
2、在下单函数入口处插入时间戳打印：print(f"[{time.time_ns()}] Submitting order")，对比交易所返回的transactTime字段。
3、将所有非关键查询（如账户余额、交易历史）迁移至独立低优先级线程，并设置ThreadPoolExecutor(max_workers=1)强制串行化。
三、时间窗口错位引发的隐性超限
交易所采用滑动窗口计数（如60秒内最多1200次），而客户端若按自然分钟重置计数器，会导致实际窗口重叠，使真实调用量翻倍而不自知。
1、禁用本地计数器，改用交易所响应头中返回的X-MBX-USED-WEIGHT与X-MBX-RESET字段进行同步校准。
2、在每次请求后解析响应头：reset_time = int(response.headers.get('X-MBX-RESET', '0'))，动态调整下一批请求的发送节奏。
3、对批量K线请求使用分段参数：将1000根1m K线拆分为5组200根，每组间隔200ms发送，避开窗口峰值。
四、密钥粒度混用放大限频风险
同一API密钥被多个策略进程、回测脚本、监控服务同时调用，总频次叠加后远超单密钥限额，但各进程均无感知。
1、登录交易所API管理后台，核查该密钥的“Last Used”时间戳是否覆盖全天多个不连续时段。
2、为每个实盘策略分配唯一密钥，并在初始化时强制校验：assert os.getenv('STRATEGY_ID') in api_key[:8]。
3、在系统启动时向交易所提交GET /sapi/v1/account/status接口，获取当前密钥的实时权重占用率。
