API 交易：从交易所 API 到执行

你的回测不下单。你的脚本也不下单。只有通过真实 API 发出去的活订单才算数——而把这步做对比做信号更难。

每个算法最终都得跟交易所或券商对话。执行层是好策略的坟场，死因通常是延迟 bug、限频、还有手滑下错的乌龙单。把它当成跟策略本身一样重要的东西来对待。

交易 API 的解剖结构

现代交易 API 大体长一个样：

1. REST 负责账户、订单管理、历史数据——简单，但慢（几十毫秒级）
2. WebSocket 负责实时行情和订单回报——快，但有状态
3. FIX 用于机构订单路由——啰嗦、快、老牌标准

典型流程：订阅行情 WebSocket，算信号，发 REST 订单，在用户数据 WebSocket 上听成交回报。

鉴权

几乎每个 API 都用签名请求方案：

signature = HMAC_SHA256(secret_key, message)

message 里包含时间戳、方法、路径和参数。交易所校验签名跟你的 API key 是否匹配。

几条不能犯的错：

• API key 永远不要提交到 git 或硬编码——用环境变量
• 用 IP 白名单，交易所支持的话
• 只交易的 key 关掉提现权限
• 定期轮换 key

订单生命周期

New → Pending → Partially Filled → Filled
                   ↓
                Cancelled / Rejected / Expired

你的执行层必须处理每个状态转换：

• 部分成交：重新评估剩余量，别重复下单
• 拒单：记下原因，别盲目重试
• 超时：轮询订单状态，永远别假设订单还活着
• 断线：重连、同步状态、再恢复——别假设任何事

搭一个安全的执行层

1. 幂等性：用 client order ID，重试提交不会重复成交
2. 下单前风控检查：发单前强制校验最大持仓、最大下单数、日内亏损上限
3. 一键停止：一个按钮（或一个 API 调用）撤销所有挂单并平仓
4. 日志：每笔订单、成交、错误、状态转换都带时间戳
5. 退避和限频：尊重 API 的限频；遇到 429 指数退避
6. 对账：定期把本地状态跟交易所回报的状态对一遍

一个最小化的下单函数

def place_order(side, symbol, qty, price):
    if qty > MAX_ORDER_SIZE:
        raise RiskError("order too large")
    if get_open_positions() + qty > MAX_POSITION:
        raise RiskError("position limit exceeded")
    client_id = uuid4()
    order = exchange.create_order(
        symbol=symbol, side=side, type='limit',
        quantity=qty, price=price, clientOrderId=client_id
    )
    log(f"submitted {client_id} {side} {qty} {symbol} @ {price}")
    return order

每一个检查都是你迟早会撞上的真实 bug。

常见坑

• 数量/价格的浮点取整 → 订单被拒
• 忘了处理 WebSocket 断线 → 行情悄悄变陈旧
• 隔夜留着的挂单 → 开盘时意外成交
• 把测试网和主网一视同仁 → 测试网订单发到主网
• 没有幂等性 → 网络重试后重复成交

小结

执行层是策略跟现实碰面的地方。鉴权要小心，每个订单状态都要处理，下单前风控必须做，日志要全。一个稳健的执行层没什么光彩——但它决定你的策略是能跑几年，还是第三天就炸。