交易所 API 对接常见的坑，你踩过几个

做量化交易系统开发，交易所 API 对接是绕不开的一环，也是最容易被低估工作量的一环。表面上看，无非是几个 REST 接口下单查单，加一个 WebSocket 订阅行情，实际做下来会发现细节非常多。 第一个坑是限流（rate limit）。几乎所有交易所都对接口调用频率有限制，而且往往按不同接口分别计算权重，下单、撤单、查询各自占用不同的配额。如果没有做好请求节流和排队机制，高频调用时很容易被限流甚至临时封禁IP或API Key，这一点在压力测试阶段就要提前验证。 第二个坑是订单状态的最终一致性。下单请求返回成功，不代表订单已经被撮合引擎处理完成；订单被交易所接受到真正成交或者被拒，中间存在时间差，而且REST查询和WebSocket推送的状态更新可能不同步。系统设计上需要一个统一的订单状态机，以某个数据源为准并处理好状态回退和重复推送的情况。 第三个坑是断线重连。WebSocket连接会因为网络波动、交易所主动断开等原因中断，重连之后必须重新订阅、并且要有机制去补齐断线期间可能错过的行情或订单更新，否则系统会基于过期或不完整的数据做决策。 第四个坑是幂等性。网络超时后到底要不要重试下单，是很容易出错的地方——如果原来的请求其实已经成功，重试会导致重复下单。规范的做法是客户端生成唯一订单号，交易所支持按这个ID去重。 第五个坑是精度和最小变动单位规则。每个交易对的价格精度、数量精度、最小名义金额都不同，下单前必须按交易所规则对价格和数量做取整处理，否则订单会被直接拒绝。 第六个坑是时钟同步。很多交易所的签名机制要求请求时间戳在一定误差范围内，服务器时钟漂移会导致请求被拒绝，需要定期做NTP校准。 这些问题单独看都不复杂，但叠加起来就是对接稳定性的主要来源，值得在系统设计初期就投入足够的测试和容错设计。