API 限速与下单频率：自动化接入交易所前必须搞懂的接口规则

策略跑着跑着下单被拒，先查的不是代码 bug

做自动化交易最常见的深夜事故是：策略正常，下单接口突然连续报错。十有八九是撞上了限速罚则。交易所对 API 的设计目标是’防滥用而不是为做市商设计的高速通道’，理解它的限速结构，是自动化接入的第一课（限速机制为行业通用描述，具体参数各平台以开发者文档当前版本为准，核验时间 2026 年 7 月）。

限速通常按什么维度计算

通用设计里有三类维度。请求权重制：不同接口计不同权重，查询余额权重低、下单撤单权重高、批量接口更高，系统在滚动时间窗内累计你的权重总和。独立下单计数：下单与撤单常有单独的更严格配额（比如按秒计数），因为撮合系统对订单流量的敏感度远高于查询。按连接与按账户：行情 WebSocket 有连接数与订阅数上限，限速可能同时挂在 API 密钥、账户与 IP 三层——同机跑多密钥共用一个出口 IP，会互相拖累。工程上最重要的一条：把这三层配额当作你的策略容量约束来设计轮询频率，而不是事后调参。

429 之后：正确与错误的退避

触发限速通常返回特定状态码，继续原速重试会触发更长的封禁期。错误做法：写一个’失败就立即重试’的循环——限速期间重试等于火上浇油。正确做法：读到拒绝响应里的恢复时间字段（多数平台会返回窗口重置时间），实现指数退避并暂停非关键查询；策略进入只读持仓的降级模式而不是继续尝试交易。更根本的方案是在代码里本地记账：每次调用扣减本地预估余额，预估接近耗尽主动降频，让真实 429 成为罕见事件而不是常态机制。

被限速之外的两个隐性成本

第一是延迟预算：查询类配额浪费在无意义轮询上，等价于给关键下单请求制造排队，合并查询、优先订阅推送（WebSocket 增量）而非 REST 轮询，能把查询配额省下来一大半。第二是撤单配额的策略设计：追单型逻辑频繁改单，撤单配额先耗尽时策略会’改不动单’，这比下单失败更危险，因为它以为自己在保护仓位而实际挂单悬空。把撤单配额纳入风控变量、设置策略侧的改单频率上限，是回测里看不到的工程细节。

灰度接入的顺序

新策略上线的稳妥顺序：先用只读密钥跑通数据管道并对账（本地持仓视图与 API 查询一致），换交易密钥小额运行并全程记录限速计数与延迟分布，观察期无异常再放大。同时给系统装上三块仪表盘：当前各维度配额水位、每日 429 次数、下单到确认的延迟分布——它们和盈亏曲线同等重要，是判断’该优化代码还是该降策略频率’的证据。

与平台规则的边界

两条纪律性提醒：自动化行为也在平台风控规则覆盖范围内，高频改单、瞬时大量撤挂即使没触发限速也可能触发异常交易审查，动手前读一遍平台的程序化交易条款；以及为绕过限速而多开密钥、多开账户摊薄配额的做法，通常违反协议并引入账户关联风险，得不偿失。速率瓶颈的正确响应永远是优化调用方式或降低频率，而不是寻找协议外通道。

风险提示

API 自动化存在程序错误导致异常下单、限速封禁导致风控操作滞后等风险，程序化交易条款与限速参数以各平台开发者文档当前版本为准。本文为接口使用科普，不构成投资建议或策略推荐（机制核验时间 2026 年 7 月）。