我做行情分析有一段时间了发现订单簿的数据其实比我们想象的要复杂。很多人用加密货币api的时候只拉全量快照或者盯着增量消息其实都不够。全量快照频繁拉取占用带宽增量推送如果没有本地快照做基础又会出现数据不完整的情况。把增量消息和本地快照结合起来才能得到真正可靠的实时深度。为什么要合并快照和增量增量推送的核心是“更新现有状态”它是基于某个快照的变化。如果直接用增量而没有初始快照就可能出现深度表不完整的情况。我的做法是先拿一次快照作为初始状态然后用增量消息去更新本地买卖列表这样深度表随时都是完整的延迟也控制得住。本地快照如何组织在代码里我通常把买卖两边用字典保存价格作为 key数量作为 value。举个例子买/卖价格数量买300001.5买299502.0卖300500.8卖301003.0这样做方便更新增量消息来了直接更新对应价格的数量或者删除数量为 0 的价格层。无需遍历整个列表效率很高。增量消息的处理方式增量推送通常包含三种操作新增、更新、删除。新增本地没有的价格层直接插入字典。更新价格层存在则覆盖数量。删除数量为 0 时删除这个价格层。有的交易所增量消息会乱序但大部分都会提供 sequence 或 timestamp 字段用来保证更新顺序。只要用这个字段校验基本不会覆盖错数据。以AllTick API 为例我在测试时把增量消息直接合并到本地快照里代码很简单import websocket import json snapshot {} def on_message(ws, message): data json.loads(message) for update in data[orders]: price update[price] quantity update[quantity] side update[side] # buy 或 sell if quantity 0: snapshot[side].pop(price, None) else: snapshot.setdefault(side, {})[price] quantity print(snapshot) ws websocket.WebSocketApp(wss://api.alltick.co/crypto/orderbook, on_messageon_message) ws.run_forever()这段代码里快照保存在本地字典里增量消息来了直接处理就行。买卖深度一直保持最新。性能优化建议如果订单层级多或者推送频繁可以考虑两点只处理差异有些消息更新了但本地没有变化的价格可以忽略减少无效操作。限制深度层数大多数策略只关注前 20-50 层更新全部深度没必要占用资源。另外价格最好用 Decimal 或者统一数据类型避免浮点精度问题尤其是计算买卖价差时。校验和稳定性增量推送方便但网络抖动可能会丢消息所以建议定期拉一次全量快照做校验频率根据交易量和策略决定一般几秒到几十秒就够。这样可以保证深度表随时可靠。我的体会把增量和快照结合实时深度几乎和交易所保持一致延迟低又可靠。在可视化或者交易策略中这种方法比只靠全量快照或者单独增量都稳。对于做行情相关开发的同学来说理解增量消息和快照的关系比盯着 API 文档里的参数更重要。