运行时行为

引擎重启后的一段时间内只接受只挂不吃的订单，吃单会被拒。窗口长度由部署配置，跨重启存续并进出快照——它不是一次性的启动抖动。

怎么处理重连后先只报 post-only，确认能吃单再放开 taker 流。把这段拒绝当作正常状态而不是故障，否则会触发你自己的熔断。

双边报价撞上自己的单子会**真的成交、真的付手续费**。撮合层没有 self-trade prevention；返佣层另有策略，自成交可能不计返佣或被标记人工复核。

怎么处理自己在报价端避免穿越，别指望服务端兜底。持续自成交除了白付手续费，还会把账户打进复核队列。

订阅 `market:{id}:book` 会先收到一次性快照再收增量；`market:{id}:trades` 与行情信息类 topic **不发快照**，只从订阅时刻起推新消息。账户类 topic 是 `account:{trader}:orders` / `positions` / `fills`。

怎么处理盘口靠快照 + 增量维护；成交与账户流要靠 REST 回补历史，不要期待订阅时拿到过去的数据。

流服务不提供断点续传或缺口重放——丢了就是丢了，服务端不会发现，也不会替你补。

怎么处理检测到本地状态可疑时**重新订阅**以拿一份新快照，而不是尝试续传。盘口对不上时重订比修补便宜得多。

做市商线的 cancel-on-disconnect：超过心跳窗口没有续期，服务端撤掉你名下全部挂单。主动注销心跳登记则**不**触发全撤——收工时挂单去留是你自己的决定。

怎么处理心跳发送频率取窗口的一半以内，留出网络抖动余量。注销是幂等的：`removed=false` 表示本来就没登记，不是错误。

链下引擎完整支持 FOK：全量成交否则整单拒绝。但**带链上签名的 FOK 单会在结算阶段失败**——结算合约把 FOK 当作保留值直接 abort，而链下这一层不会替你拦：订单被正常受理、返回 202、冻结资金，最后卡在结算。

怎么处理签名单一律用 GTC 或 GTD。FOK 只用在不带签名的链下单上。

写接口返回的 cursor 拿去查状态时，投影落后几毫秒是常态。此时返回 404，与「订单不存在」**逐字节不可区分**。

怎么处理带同一个 cursor 重试，不要把第一个 404 当成下单失败而重发——那会变成两笔单（除非你传了 clientOrderId）。