第一次把自己写的脚本或机器人接到交易所接口上的人，多半会在某个行情剧烈时段收到一串 429。这个HTTP状态码的含义是请求太多、被限流了，但把它当成一个按钮问题去解决的人，往往会让情况更糟。本文机制说明撰写于 2026 年 9 月，按计量口径、配额结构、重试纪律、排查顺序四块拆解，具体数字以各平台官方 API 文档为准，本文不写死任何配额。
先分清两种计量。最直观的是请求数限制：单位时间内每个来源能发多少次调用，超了拒掉。更常见的却是权重制：每个接口按开销赋权，查询撮合深度的接口权重高，查询单个交易对状态的权重低，你的调用消耗的是权重总额而不是次数。这意味着两个脚本发起同样每秒十次请求，一个可能绰绰有余，另一个几秒就撞墙。读文档时先看你的接口清单各自权重，再算总账；行情剧烈时的轮询频率才是压垮配额的真正来源。
配额通常按池子分开。公开行情端点与需要签名的私有端点是两套独立的桶：你查账户、下单的调用不占行情配额，反之亦然。更隐蔽的一层是来源归因：不少平台对未登录请求按 IP 归组限流，如果脚本跑在共享出口的企业网络或热门机房，你会替同一出口的所有人排队。表现是白天时松时紧、换网络立刻正常——这时问题根本不在你的代码。
收到 429 之后的纪律比技巧重要。第一反应不该是立刻重试，更不该是写一个失败就原样重发的循环：那会在系统已经紧张时制造请求风暴，把短时降速变成持续封禁。通行做法是指数退避加随机抖动——失败一次等两倍于上次的时间再试，等待上限设几秒到几十秒；若响应头带回了建议等待时间，优先遵守它。对延迟敏感的关键下单路径，正确设计是预先分配好配额、把重试用在幂等性有保证的查询上，下单动作靠幂等参数而不是盲目重发。
排查顺序建议这样走：先看报错来自哪一层，是接口直接拒绝还是网关超时；再确认被限的是 IP 池还是账户配额，多数平台在被拒响应里会说明维度，文档里也有字段对照；然后翻自己代码的调用密度，重点找错误处理分支里的紧循环——最凶的请求风暴几乎都出在异常处理写错的地方。策略开发期把日志里的被拒计数当告警指标，长期贴配额上限运行说明架构需要改成推送订阅而不是轮询。
适合做这件事的人：能维护自己脚本、看得懂响应头、接受断线重连设计的用户。不适合的人：指望抄一段轮询脚本就稳定拿数据的用户——行情剧烈时段恰恰是你最需要数据、配额最先耗尽的时段，脚本会在最关键的时刻先倒下。这类需求更合理的归宿是平台的推送通道或成熟数据服务，而不是加更多重试。最后补一条常被忽略的合规线：用公开接口抓数据做个人看盘与对外再分发是两回事，多数平台的开发者条款对缓存时限、署名要求与商业转售各有约束，把抓下来的行情喂给自建信号服务或社群机器人之前，先读完接入协议那一节，再决定架构。同样的纪律也适用于密钥管理：查询类脚本优先用只读权限、关闭提币开关、限制来源地址，把接口身份和资金身份彻底分开，任何一次为省事而给全权限密钥的做法，都会在脚本长期无人值守运行后被放大成真实风险。
风险提示：自动化接入存在故障放大与执行偏差风险，接口行为可能随平台调整变化。本文仅为机制说明，不构成任何交易执行或收益承诺，亦不构成投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。