加密交易所 API 速率限制披露审计：Binance、Coinbase、Gate 与 OKX

已核验的来源事实

1. Binance 公开了请求权重与订单计数限制，超限返回 429，持续违反限制还可能触发逐步加重的 418 IP 封禁。 2. Coinbase Exchange 按 IP 计算公开 REST 限制、按账户档案计算私有限制，并使用带独立突发容量的延迟填充令牌桶。 3. Gate API v4 分别公布公开、私有、下单、撤单、钱包与提现端点的限制，并说明持续超量请求可能被延迟或拒绝。 4. OKX 对公开 REST、私有 REST、WebSocket 订单管理、按合约交易限制与子账户总请求使用不同计数键。

对照表

1. 控制测试：计数键

交易控制披露只有转换成可测试规则才有意义。计数键需要检查IP、API 密钥、账户档案、用户、子账户或合约。应使用沙箱、非生产环境或最小可逆测试，然后在每个端点旁保存准确计数键。可以保存配置和事件证据，但绝不能记录凭据，并应验证文档所述的撤单、拒绝、减量或历史记录行为。

审计要模拟失败路径，而不只看设置流程。需要追问哪套策略拥有 maker 与 taker 订单、平台按哪个账户边界判断、哪个消息能证明干预，以及部分成交或断线后如何对账。平台文档只能说明支持什么，不能证明操作者配置正确。内部共享限制因此必须保留为明确缺口。

计数键这一行最终应形成一条与IP、API 密钥、账户档案、用户、子账户或合约绑定的监控规则。执行者应在每个端点旁保存准确计数键，保存平台响应，并为异常指定责任人。文档质量是积极信号，但不能认证交易所或交易系统；在真实观察之前，内部共享限制仍是独立生产风险。

2. 控制测试：时间窗口

时间窗口需要检查每秒、每两秒或滚动令牌桶。应使用沙箱、非生产环境或最小可逆测试，然后统一展示但不丢失突发语义。

审计要模拟失败路径，而不只看设置流程。动态等级变化因此必须保留为明确缺口。

时间窗口这一行最终应形成一条与每秒、每两秒或滚动令牌桶绑定的监控规则。执行者应统一展示但不丢失突发语义，保存平台响应，并为异常指定责任人。文档质量是积极信号，但不能认证交易所或交易系统；在真实观察之前，动态等级变化仍是独立生产风险。

3. 控制测试：请求成本

请求成本需要检查一次调用还是加权请求单位。应使用沙箱、非生产环境或最小可逆测试，然后读取端点特定权重。

审计要模拟失败路径，而不只看设置流程。未来权重变化因此必须保留为明确缺口。

请求成本这一行最终应形成一条与一次调用还是加权请求单位绑定的监控规则。执行者应读取端点特定权重，保存平台响应，并为异常指定责任人。文档质量是积极信号，但不能认证交易所或交易系统；在真实观察之前，未来权重变化仍是独立生产风险。

4. 控制测试：订单限制

订单限制需要检查新建、改单、撤单与未成交订单计数。应使用沙箱、非生产环境或最小可逆测试，然后分别跟踪每个计数器。

审计要模拟失败路径，而不只看设置流程。撮合引擎例外因此必须保留为明确缺口。

订单限制这一行最终应形成一条与新建、改单、撤单与未成交订单计数绑定的监控规则。执行者应分别跟踪每个计数器，保存平台响应，并为异常指定责任人。文档质量是积极信号，但不能认证交易所或交易系统；在真实观察之前，撮合引擎例外仍是独立生产风险。

5. 控制测试：突发容量

突发容量需要检查稳定速率之外的临时容量。应使用沙箱、非生产环境或最小可逆测试，然后客户端实现令牌桶。

审计要模拟失败路径，而不只看设置流程。未披露的平滑规则因此必须保留为明确缺口。

突发容量这一行最终应形成一条与稳定速率之外的临时容量绑定的监控规则。执行者应客户端实现令牌桶，保存平台响应，并为异常指定责任人。文档质量是积极信号，但不能认证交易所或交易系统；在真实观察之前，未披露的平滑规则仍是独立生产风险。

6. 控制测试：响应信号

响应信号需要检查响应头、错误码、429 或 418。应使用沙箱、非生产环境或最小可逆测试，然后解析并保留平台信号。

审计要模拟失败路径，而不只看设置流程。WAF 判断歧义因此必须保留为明确缺口。

响应信号这一行最终应形成一条与响应头、错误码、429 或 418绑定的监控规则。执行者应解析并保留平台信号，保存平台响应，并为异常指定责任人。文档质量是积极信号，但不能认证交易所或交易系统；在真实观察之前，WAF 判断歧义仍是独立生产风险。

7. 控制测试：退避

退避需要检查Retry-After 与指数延迟。应使用沙箱、非生产环境或最小可逆测试，然后状态未知时停止自动重试。

审计要模拟失败路径，而不只看设置流程。封禁持续时间因此必须保留为明确缺口。

退避这一行最终应形成一条与Retry-After 与指数延迟绑定的监控规则。执行者应状态未知时停止自动重试，保存平台响应，并为异常指定责任人。文档质量是积极信号，但不能认证交易所或交易系统；在真实观察之前，封禁持续时间仍是独立生产风险。

8. 控制测试：未知订单

未知订单需要检查超时不能证明下单失败。应使用沙箱、非生产环境或最小可逆测试，然后重新提交前先查询订单状态。

审计要模拟失败路径，而不只看设置流程。延迟成交因此必须保留为明确缺口。

未知订单这一行最终应形成一条与超时不能证明下单失败绑定的监控规则。执行者应重新提交前先查询订单状态，保存平台响应，并为异常指定责任人。文档质量是积极信号，但不能认证交易所或交易系统；在真实观察之前，延迟成交仍是独立生产风险。

9. 控制测试：WebSocket

WebSocket需要检查连接、订阅与入站消息限制。应使用沙箱、非生产环境或最小可逆测试，然后单独预算重连行为。

审计要模拟失败路径，而不只看设置流程。网络中断因此必须保留为明确缺口。

WebSocket这一行最终应形成一条与连接、订阅与入站消息限制绑定的监控规则。执行者应单独预算重连行为，保存平台响应，并为异常指定责任人。文档质量是积极信号，但不能认证交易所或交易系统；在真实观察之前，网络中断仍是独立生产风险。

10. 控制测试：运维

运维需要检查监控、告警与安全降级。应使用沙箱、非生产环境或最小可逆测试，然后为每个平台定义熔断器。

审计要模拟失败路径，而不只看设置流程。生产流量形状因此必须保留为明确缺口。

运维这一行最终应形成一条与监控、告警与安全降级绑定的监控规则。执行者应为每个平台定义熔断器，保存平台响应，并为异常指定责任人。文档质量是积极信号，但不能认证交易所或交易系统；在真实观察之前，生产流量形状仍是独立生产风险。

决策场景

场景 1：当计数键成为关键约束

假设读者最关心的是IP、API 密钥、账户档案、用户、子账户或合约，正确做法不是寻找一个适用于所有人的赢家，而是在每个端点旁保存准确计数键，保存证据，并在投入资金或权限前定义停止条件。只要证据变化，就重新打开决策，而不是继续沿用旧结论。这样得到的是一条能够重复执行的操作规则，而不是一次性的主观看法。

场景 2：当时间窗口成为关键约束

假设读者最关心的是每秒、每两秒或滚动令牌桶，正确做法不是寻找一个适用于所有人的赢家，而是统一展示但不丢失突发语义，保存证据，并在投入资金或权限前定义停止条件。

场景 3：当请求成本成为关键约束

假设读者最关心的是一次调用还是加权请求单位，正确做法不是寻找一个适用于所有人的赢家，而是读取端点特定权重，保存证据，并在投入资金或权限前定义停止条件。

场景 4：当订单限制成为关键约束

假设读者最关心的是新建、改单、撤单与未成交订单计数，正确做法不是寻找一个适用于所有人的赢家，而是分别跟踪每个计数器，保存证据，并在投入资金或权限前定义停止条件。

场景 5：当突发容量成为关键约束

假设读者最关心的是稳定速率之外的临时容量，正确做法不是寻找一个适用于所有人的赢家，而是客户端实现令牌桶，保存证据，并在投入资金或权限前定义停止条件。

场景 6：当响应信号成为关键约束

假设读者最关心的是响应头、错误码、429 或 418，正确做法不是寻找一个适用于所有人的赢家，而是解析并保留平台信号，保存证据，并在投入资金或权限前定义停止条件。

常见问题

本文是否建议使用或避开某个平台或产品？

不是。它是一套基于来源的决策框架。最终结论取决于用户地区、签约实体、账户、产品、交易规模、风险承受能力与实时条款。

公布的费率或控制措施是否永久有效？

不是。公开费率和控制规则会变化，实际条款也可能针对账户。应核对登录后的实时页面。

页面返回 HTTP 200 是否证明产品正常可用？

不能。公开页面存在，不代表特定地区或账户一定能使用该产品，账户级证据才是最终依据。

为什么必须公开列出未知事项？

因为用假设填补证据空白会制造虚假精确。未知事项说明下一步应该核验什么。

最安全的第一步是什么？

写清具体任务，核验官方来源，采用最小权限和最可逆的路径，并在适合时先做小额测试。