加密货币交易所 API 限流详解
1. “API 限流”是什么意思
从纸面上看，API 限流很简单。它规定了交易所在一个固定时间窗口内会接受多少请求，比如 1 秒、1 分钟或 1 小时。这就是“加密货币交易所 API 限流详解”的核心概念。
不要把限流和手续费混为一谈。手续费是对交易、提现或服务等级收取的费用；限流则是一种流量规则。如果你的客户端每分钟发出 200 个请求，而交易所只允许 120 个，那么第 121 个请求即使账户免费也可能失败，也可能直接触发交易所 API 429 错误。
限流也不同于账户等级。有些交易所会给已验证用户、做市商或付费套餐更高的限额，但限流依然存在。某个等级可能每秒允许 10 个请求，另一个则允许 50 个。交易所仍然是在划线设定边界，而这也是理解如何避免交易所接口限流的第一步。
可以把它理解为：限流就是 API 的“门禁规则”。你可以进入，但不能一下子全挤进去。忙碌时段尤其如此。
2. 交易所为什么要做限流
交易所设置限流主要有三个直接原因：保护基础设施、减少滥用、并在流量激增时保持系统稳定。市场可能在 30 秒内快速波动，而脚本洪流会同时压垮订单簿、余额查询和价格接口。如果某个客户端发送过多调用，所有人都会受到影响。
还有公平性的问题。没有限流的话，一个激进的机器人可能会疯狂轰击公共接口，把小用户挤出去。这不是理论，而是新币上线或剧烈抛售把请求量推高时常见的现实问题。
有些限制是为了阻止抓取、滥用或意外死循环。一个坏掉的循环可能会在没人注意时把同一个请求发送 500 次。交易所看到的是一场“风暴”，而不是一次意外。
不过，限流不只是防御。它还能帮助交易所在流量上升时保持市场数据新鲜、订单系统响应及时。相比会被突发洪峰压垮的 API，稳定的 API 更值得信赖。
3. 限流是如何衡量的
大多数交易所按每秒请求数或每分钟请求数来衡量限流。也有一些会采用混合机制：一个较小的每秒上限，加上一个更大的每分钟上限。交易所还可能给不同接口分配不同权重。简单的价格查询可能算 1 个单位，而下单或历史查询可能算更多。
按接口单独设限很常见。公共行情接口通常比私有余额接口允许更多调用。公共接口与认证接口分开限流的情况也很常见。
有些 API 允许短时突发。这意味着你可以在几秒内短暂超过稳态速率，只要平均值仍符合规则。另一些则非常严格，完全不给突发空间。差异会直接影响你如何编写客户端。
重点看三个东西：单位、时间窗口和权重。这三个数字基本就能说明问题。如果页面只写着“已限流”，那远远不够。
4. 限流在真实工作流中的表现
限流最先出现在日常任务里。一个每 2 秒刷新一次价格的交易者，如果应用同时检查 20 个市场，很快就会碰到上限。一个每 5 秒同步一次余额的开发者，起初可能没问题，但当钱包列表从 3 个资产增加到 30 个时，失败就会突然出现。
下单流程也是高压点。一个会测试信号、撤销过期订单并重新提交新订单的机器人，可能很快就会耗尽请求额度，尤其在高波动时期。前一分钟系统还很安静，12 次价格跳动之后就不再安静了。
历史回填更容易被低估。拉取 90 天的 K 线、成交历史或订单回报，往往意味着成千上万次请求；如果交易所没有批量接口，每次请求都要和实时流量争夺资源。如果 API 每次只返回 100 行，计算量会迅速变得难看。
轮询本质上是时间上的隐性成本，而不是金钱成本。一个每秒检查五个接口的仪表盘，在测试时看起来无害，但真实用户一登录，就可能把限流打穿。这也是为什么很多团队在经历第一个“磨合月”后，会从轮询转向 WebSocket。
5. 常见警告信号与失败模式
最明显的信号通常是 HTTP 错误，最常见的是 429，表示请求过多。有些交易所会返回清晰的信息；另一些则给出通用失败结果，要求客户端自己读取响应头。虽然不友好，但很常见。
临时降速也是一种结果。API 可能会先放慢响应，再开始拒绝调用。你发出一个请求，然后等待 1.5 秒才拿到原本 120 毫秒就能返回的答案。这个延迟就是即将限流关闭的警告。
有些平台在多次违规后会进入封禁窗口。封禁可能持续 30 秒、5 分钟，或者更久。在严重情况下，交易所会封锁 IP 地址或 API 密钥。如果机器人还在盲目重试，惩罚只会更重。
即便没有明确的限流提示，也可能出现订单被拒。交易请求可能失败，因为客户端已经用完了允许的突发额度，尽管同一账户仍然可以获取公共数据。这种不一致会让很多团队在首次接入时感到困惑。
6. 如何读懂交易所的限流规则
先看文档，但不要只看第一张表。留意接口权重、冷却规则，以及异常说明。某一页可能写着“每秒 10 个请求”，却在后面悄悄注明订单接口每次权重为 5。这样一来，实际可用容量会小得多。
响应头很重要。许多交易所会在响应中发送限流相关头信息，通常能显示剩余请求数、重置时间，或者当前调用是否消耗了额外权重。如果文档写得含糊，响应头通常更明确。
注意隐藏的例外。公共市场数据可能适用一套规则，而私有交易调用适用另一套。WebSocket 连接也可能有单独的连接限制。如果你只读第一段，很可能会漏掉真正关键的部分。
团队在接入前通常会保留一份简单检查清单。如果你想看更全面的上线前清单，加密货币交易所安全检查清单这篇文章会很有帮助，因为当 API 密钥被暴露或滥用时，限流错误和安全错误往往会一起出现。
也要留意文档措辞。简短的表述可能掩盖真实约束。如果页面写着“公平使用”，就追问具体数值；如果写着“可能会变更”，就追问由谁变更、多久变一次。这个答案在生产环境出问题之前就该弄清楚，而不是出故障之后。
7. 值得了解的限流术语
Throttle（降速）是指交易所故意放慢你的请求。这还不算失败，但已经很接近了。你仍然可能拿到响应，只是比平时慢。
Quota（配额）是某个时间段内的总额度。如果配额是每分钟 100 个请求，那么这个数字会在分钟窗口结束时重置。配额就是预算，要谨慎使用。
Burst allowance（突发额度）是 API 可能额外给你的短时空间。即使稳态速率只有每秒 5 个请求，短时间内发 20 个请求也可能没问题。关键在于平均值仍然必须符合规则。
Backoff（退避）是下一次重试前的等待时间。一个先等 250 毫秒，再等 500 毫秒，再等 1 秒的客户端，看起来就像一个有耐心的人；而立即重试的客户端，看起来更像出了故障。
Ban window（封禁窗口）是违规后交易所阻止你继续发请求的那段时间。Weighted requests（加权请求）是指并非按 1 个单位计算的调用。如果某个接口权重为 10，那么 10 次这样的调用可能会消耗掉相当于 100 次轻量请求的额度。这种细节，足以让机器人在凌晨 3 点失灵。
8. 示例：典型限流场景
示例 1：一个查价应用。假设应用监控 8 个交易对，并每 5 秒刷新一次。听起来负载不高，但如果每次刷新都要访问独立的公共接口，而交易所每秒只允许 10 个请求，那么在用户增多、同一台服务器开始服务 50 个会话时，限流就会开始显现。
示例 2：一个交易机器人。机器人会检查信号、下单、撤销过期订单并确认成交。如果每个动作都使用权重更高的认证接口，那么机器人可能在几个快速循环后就触碰到限制。更谨慎的机器人会使用缓存状态、更少的余额检查，以及在每次失败后逐步增长的重试延迟。
示例 3：一个数据密集型回填任务。一个下载 180 天 K 线数据的研究脚本，可能在完成前很久就触发限流。如果交易所每次请求只返回 200 行，那么这个任务可能需要数百次调用。更好的方式是按天分批、每个区块之间暂停，并在失败后从最后一个干净时间戳继续。
如果你正在为这些场景比较平台，交易所的选择和代码同样重要。像如何选择加密货币交易所这样的实用指南，在你判断 API 设计是否适合工作流时会很有帮助，而不只是看交易界面是否好看。
还有第二类值得一提的例子：看起来很干净的 API，在高负载下却依然表现很差。有些项目在沙盒里看起来没问题，一到线上接口就失败，因为生产环境的限流规则更严格。这就是为什么只靠测试数据永远不够。
再补充一个实用建议。如果你想保护客户端免于被封禁，阅读如何验证加密货币交易所可以帮助你在把真实流量交给平台之前，先检查它是否公布了清晰规则、支持联系方式以及一致的 API 行为。
对于开发机器人或仪表盘的读者来说，最干净的修复方案通常不是“发得更快”，而是“发得更少”。把结果缓存 3 秒，停止重复调用，避免在一个循环里两次请求同样的余额。这种小小的纪律，能让 API 保持平稳，也让日志更易读。
最后再说一句：如果某个文档页面模糊到你连一次请求到底算 1 个单位还是 5 个单位都判断不出来，那就把它当成警告，而不是谜题。去问支持团队准确限额、重置窗口和超额惩罚。那些不是装饰性的细节，而是决定集成能否撑过第一个高峰时段的关键因素。
