一、订单簿基础：从零开始理解这个核心
做量化交易这些年，我见过不少新手一上来就盯着K线图猛看，却忽略了最底层的东西——订单簿。说实话，订单簿才是市场的真实面貌，K线图不过是它的“二手加工品”。今天我们就从最基础开始，把订单簿彻底讲透。
1.1 什么是订单簿？
订单簿，说白了就是一个“挂单本”。它记录了所有交易者挂出来的、还没成交的买卖意愿。
你想想看，你去菜市场买菜，有人喊“我出5块买一斤”，有人喊“我6块卖一斤”。这些喊价如果没成交，就会被记在一个本子上——这就是订单簿的雏形。
在电子交易中，订单簿就是交易所服务器里的一张表。左边是买单，右边是卖单。每一笔都记录着：谁想买/卖、什么价格、多少数量。
核心要点：订单簿是市场微观结构的核心。它反映了所有市场参与者的真实意图，是价格发现的引擎。
1.2 限价单与市价单
这两种订单类型，是交易系统里最基础的操作。我刚开始做策略时，就因为搞混了它们吃过亏。
限价单（Limit Order）
限价单就是“我只接受这个价格或更好的价格”。比如我挂一个“买入BTC，限价50000”，那系统只会帮我买价格≤50000的卖单。
- 优点：价格可控，不会买贵了
- 缺点：可能一直成交不了
- 我遇到过：有一次做套利策略，限价单挂得太保守，结果行情一飞冲天，我愣是没上车。后来我学会了根据订单簿深度动态调整限价。
市价单（Market Order）
市价单就是“不管价格多少，我现在就要成交”。系统会以当前最优的可成交价格帮你吃掉对手单。
- 优点：立即成交，确定性高
- 缺点：价格不可控，可能滑点严重
- 避坑指南：我曾经在流动性不足的品种上用了市价单，结果滑了3个tick，直接亏掉当天的利润。记住：市价单是“用价格换速度”。
我的习惯：做高频策略时，我倾向于用限价单做市；做事件驱动策略时，用市价单抢速度。没有绝对的好坏，看场景。
1.3 买卖盘口与价差
盘口，就是订单簿里最前面那几档价格。买一、买二、买三...卖一、卖二、卖三...
价差（Spread），就是卖一价减去买一价。这个数字越小，说明市场流动性越好。
| 盘口 | 买单（Bid） | 卖单（Ask） |
|---|---|---|
| 第1档 | 买一：50000，10手 | 卖一：50002，8手 |
| 第2档 | 买二：49998，15手 | 卖二：50004，12手 |
| 第3档 | 买三：49996，20手 | 卖三：50006，18手 |
价差 = 50002 - 50000 = 2个tick
为什么会关注价差？因为它直接决定了你的交易成本。你想想看，如果你用市价单买入，你吃的是卖一价；如果立刻用市价单卖出，你只能吃到买一价。这一来一回，价差就是你的成本。
注意：价差不是固定的。市场波动大时，价差会迅速扩大。我见过极端行情下，价差从2个tick瞬间扩大到50个tick。这时候做市策略一定要暂停。
1.4 订单簿数据结构
做量化交易，订单簿的数据结构必须烂熟于心。我习惯用Python的字典或pandas的DataFrame来模拟。
一个典型的订单簿数据结构长这样：
# 订单簿数据结构示例
order_book = {
'bids': [ # 买单，按价格从高到低排序
{'price': 50000, 'volume': 10, 'order_id': 'bid_001'},
{'price': 49998, 'volume': 15, 'order_id': 'bid_002'},
{'price': 49996, 'volume': 20, 'order_id': 'bid_003'},
],
'asks': [ # 卖单，按价格从低到高排序
{'price': 50002, 'volume': 8, 'order_id': 'ask_001'},
{'price': 50004, 'volume': 12, 'order_id': 'ask_002'},
{'price': 50006, 'volume': 18, 'order_id': 'ask_003'},
],
'timestamp': 1699000000000, # 毫秒级时间戳
'symbol': 'BTC/USDT'
}实际生产环境中，订单簿的数据结构会更复杂。交易所通常会用红黑树或跳表来维护，保证插入、删除、查询都在O(log n)时间内完成。
嗯，这里要注意：订单簿的更新是增量式的。交易所不会每次都给你全量数据，而是发一个“增量快照”——告诉你哪个订单被撤了、哪个新订单进来了、哪个订单被成交了。你的程序需要维护一个本地的订单簿副本，实时应用这些增量。
我的经验：维护订单簿时，一定要处理好“脏数据”。网络延迟、数据包乱序都可能导致订单簿状态不一致。我一般会加一个序列号校验，如果发现序列号跳跃，就请求一次全量快照重新同步。
知识体系总览
下面这张图，是我自己梳理的订单簿知识体系。你可以把它当作本章的“地图”：
这张图把本章的知识点串起来了。你可以看到，订单簿不是孤立的概念——它连接着订单类型、盘口分析、数据结构实现。每一个分支都值得深入。
好了，第一章就到这里。订单簿这个东西，你越早吃透，后面的路就越顺。我当年就是花了整整一个月才把订单簿的增量更新逻辑调通，现在想想，那段时间的投入太值了。