券商 API 接入实战：交易所、IBKR、FXCM

连券商 API 是大多数散户 algo 死的地方。回测里信号好好的，一上实盘就被延迟、断线、未文档化的错误码静悄悄地吃掉订单。每类券商有自己的死法。

加密交易所（Binance、Bybit、Kraken）

下单走 REST，行情走 websocket。关键坑：

• 限频：Binance 每分钟 1200 权重；一次 fetch_ohlcv 带 limit=1000 花费 2 权重。用 X-MBX-USED-WEIGHT 响应头做自我节流。
• websocket 断线：服务器每 24 小时强制重启。实现指数退避重连（1s、2s、4s，封顶 30s），重连后用 REST 重新同步——别信旧流。
• 精度：每个 symbol 有自己的 tickSize 和 stepSize。在 3 位小数的 symbol 上提交 0.0012345 BTC 会被静默拒绝。先 exchange.load_markets()，再用 exchange.amount_to_precision() 取整。

Interactive Brokers（TWS API / IB Gateway）

IBKR 强但有状态、异步。要点：

• 24/7 自动化跑 IB Gateway（不是 TWS）；TWS 每晚自动登出。
• 用 reqId 关联；响应会乱序到达。维护一个 reqId → 待办动作的 dict。
• 显式处理错误码：1100（连接丢失）、200（证券未找到）、201（订单被拒）。1100 意味着你的实时订单状态现在不可信——手动平仓。
• 用 genericTickList 申请行情，别为用不上的 tick 付费。
• IBKR 上限每秒 50 条消息。一突发就被无声节流。

FXCM（及类似外汇券商）

FXCM 的 REST API 很薄。要点：

• 每个 symbol 要订阅；不用的取消订阅降噪。
• token 每小时过期；50 分钟主动刷新，别等反应式。
• 数据行情下止损单滑点大——只在提供保证止损的地方用保证止损，并给 NFP/CPI 那几分钟预算 2 倍正常点差。

通用模式

1. 幂等性：附带客户端订单 ID。重连或超时后，先按 ID 查再重发。这是接入实践里杠杆最高的一条。
2. 订单状态机：跟踪 SUBMITTED → PARTIAL → FILLED → CANCELLED。永远别假设；只在确认回调上转状态。
3. 对账循环：每 60 秒从券商查一次挂单和持仓，跟内部状态对账。漂移意味着丢了回调。
4. 延迟预算：测往返时间。加密超过 250ms 或 IBKR 超过 500ms，你的成交就会偏离回测。

接入测试

上真金白银前：对着 paper 端点跑 14 天接入测试，每 4 小时故意断一次网，验证零重复、零丢失订单。测试过不了，实盘会更糟。