3. 交易所分类与特点：CEX vs DEX，主流交易所API风格对比
做量化交易，第一件事就是选交易所。
你想想看，交易所就像你的战场。选错了战场，策略再好也白搭。我个人习惯把交易所分成两大类：中心化交易所（CEX）和去中心化交易所（DEX）。这两者的API风格、数据质量、延迟特性，完全是两个世界。
3.1 CEX vs DEX：本质区别
先说CEX。说白了，就是传统意义上的交易所，比如Binance、OKX、Coinbase。你的资产托管在交易所的服务器上，交易撮合也在他们的服务器里完成。你通过API发送订单，交易所帮你执行。
DEX就不一样了。它是跑在区块链上的智能合约。你的资产在你自己的钱包里，交易直接在链上完成。没有中间商，但代价是——慢，而且贵。
核心差异一句话总结：
- CEX：速度快（微秒级撮合）、深度好、功能全，但你要信任交易所
- DEX：去信任化、资产自管，但速度慢（秒级）、Gas费高、流动性分散
我在项目中遇到过不少团队，一开始想搞DEX量化，觉得去中心化很酷。结果发现，一个套利策略在CEX上跑得好好的，搬到DEX上，Gas费就把利润吃光了。嗯，这里要注意：DEX更适合做长线、大额、低频的交易，高频量化还是得靠CEX。
3.2 主流CEX的API风格对比
做交易所对接，我最关心的就三件事：认证方式、数据格式、WebSocket稳定性。下面我拿Binance、OKX、Coinbase这三个主流交易所，说说我的实战感受。
| 维度 | Binance | OKX | Coinbase |
|---|---|---|---|
| API认证 | HMAC SHA256 + API Key | HMAC SHA256 + API Key + Passphrase | JWT Token + API Key |
| REST接口 | RESTful，JSON格式 | RESTful，JSON格式 | RESTful，JSON格式 |
| WebSocket | 稳定，支持多流合并 | 稳定，但需要心跳维护 | 相对较弱，断连较多 |
| 限频策略 | 基于权重，每分钟1200权重 | 基于接口，每秒60次 | 基于速率，每秒10次 |
| 订单类型 | LIMIT/MARKET/STOP_LOSS等 | LIMIT/MARKET/TRIGGER等 | LIMIT/MARKET/STOP等 |
| 文档质量 | 优秀，示例代码齐全 | 良好，但更新较慢 | 一般，部分接口描述模糊 |
3.3 认证方式：看似一样，细节不同
Binance的认证方式比较经典。你需要把API Key放在请求头里，然后用Secret Key对请求参数做HMAC SHA256签名。我刚开始对接的时候，踩过一个坑：签名时参数必须按字母序排序。有一次我忘了排序，结果一直报签名错误，排查了半天。
// Binance 签名示例（Python）
import hmac
import hashlib
def sign_request(params, secret_key):
query_string = '&'.join([f"{k}={v}" for k, v in sorted(params.items())])
signature = hmac.new(
secret_key.encode(),
query_string.encode(),
hashlib.sha256
).hexdigest()
return signatureOKX的认证稍微复杂一点。除了API Key和Secret Key，它还需要一个Passphrase。而且签名的时候，需要把时间戳、请求方法、请求路径、请求体全部拼起来。我一开始觉得多此一举，后来发现这样确实更安全——即使API Key泄露，没有Passphrase也白搭。
避坑指南：我曾经在OKX的WebSocket认证上栽过跟头。它的WebSocket登录需要先发送一个登录消息，里面包含签名。但签名用的时间戳必须和服务器时间同步，误差超过5秒就会被拒绝。所以，对接OKX之前，一定要先做时间同步。
Coinbase用的是JWT Token。说实话，我个人不太喜欢这种方式。JWT有过期时间，你需要定期刷新。而且它的API Key权限管理比较粗粒度，不像Binance那样可以精确控制每个接口的权限。
3.4 WebSocket：谁更稳？
做高频交易，WebSocket就是生命线。数据断流几秒钟，你的策略可能就亏钱了。
Binance的WebSocket是我用过最稳的。它支持多数据流合并到同一个连接，比如你可以同时订阅BTCUSDT的深度、成交、K线，都在一个连接里。而且它的重连机制做得很好，断线后会自动重连，不会丢数据。
OKX的WebSocket也不错，但有个烦人的地方——它要求客户端定期发送心跳包。如果超过30秒没发心跳，服务器就会断开连接。我一开始没注意这个，结果策略跑着跑着就断线了。后来我加了个定时器，每15秒发一次心跳，问题就解决了。
注意：Coinbase的WebSocket稳定性相对较差。我在生产环境中遇到过多次断连，而且它的重连机制不太智能，有时候需要手动重连。如果你要做高频策略，建议优先考虑Binance或OKX。
3.5 限频策略：别被误封
每个交易所都有限频策略。Binance用的是权重制，每个接口消耗不同的权重。比如查询账户信息消耗10权重，下单消耗1权重。每分钟总权重上限是1200。我建议你在代码里做一个权重计数器，避免超限。
OKX的限频更直接——每秒60次请求。超过就会被封IP。我曾经在回测时忘了加限速，结果把OKX的API打爆了，被封了半小时。嗯，从那以后我写了个限流器，严格控制请求频率。
Coinbase的限频最严格，每秒只有10次。而且它的限频是全局的，不是按接口算的。所以对接Coinbase时，一定要把请求频率降下来，否则很容易被封。
3.6 知识体系总览
下面这张图，是我对交易所分类与API风格的整体理解。你可以把它当作一个快速参考。
3.7 实战建议
如果你刚开始做交易所对接，我建议你从Binance开始。它的文档最全，社区最活跃，遇到问题很容易找到答案。而且它的API设计很规范，学会了Binance，再学OKX和Coinbase就快多了。
如果你要做跨交易所套利，那就要同时对接多个交易所。这时候，我建议你封装一个统一的API层，把不同交易所的认证、签名、限频逻辑抽象出来。这样，切换交易所时只需要改配置，不用改业务代码。
一个小技巧：我在项目中用了一个叫 ccxt 的库，它封装了上百个交易所的API。虽然性能不如直接对接，但做原型验证和回测时非常方便。等策略稳定了，再换成原生API也不迟。
最后，记住一点：交易所API对接没有银弹。每个交易所都有自己的脾气，你需要花时间去熟悉、去测试。别指望一套代码跑遍所有交易所——至少我试过，结果很惨。
公众号:蓝海资料掘金营，微信deep3321