一、订单簿基础：限价单与市价单、买卖盘口、订单簿数据结构、Level1/Level2/Level3数据区别

做量化交易这些年，我越来越觉得订单簿是市场最真实的脉搏。你想想看，所有交易者的意图、情绪、策略，最终都浓缩在那一串数字里。今天我们就从最基础的东西聊起——订单簿到底是个什么玩意儿。

1.1 两种最基础的订单类型

先说说限价单和市价单。这两个概念，说白了就是「我想用什么价格买」和「我不管价格，立刻成交」。我个人习惯把限价单叫做「耐心单」，把市价单叫做「急迫单」。

限价单（Limit Order）：你指定一个价格，只有市场达到这个价格时才会成交。比如你想在100元买入某只股票，那就挂一个限价买单。市场不到100元，单子就一直在那等着。

市价单（Market Order）：你不管价格，只求立刻成交。系统会以当前最优的可成交价格帮你吃掉对手盘。我刚开始做交易时，有一次用市价单买小盘股，结果滑点吃了大亏——嗯，从那以后我再也不敢在流动性差的品种上用市价单了。

1.2 买卖盘口：订单簿的骨架

订单簿的核心结构就是买卖盘口。买盘（Bid）是所有人想买入的价格和数量，卖盘（Ask）是所有人想卖出的价格和数量。两者之间的空隙，就是所谓的「价差」（Spread）。

举个例子，假设某股票当前订单簿长这样：

卖盘（Ask）	价格	买盘（Bid）
200股 @ 10.05	10.05
500股 @ 10.04	10.04
	10.03	300股 @ 10.03
	10.02	800股 @ 10.02
	10.01	100股 @ 10.01

这里最佳买价（Best Bid）是10.03，最佳卖价（Best Ask）是10.04，价差只有1分钱。流动性好的股票，价差通常很小。我记得有一次做期权订单簿分析，价差大到离谱，一看就是做市商在放假——这种时候千万别用市价单。

1.3 订单簿的数据结构

做量化的人，必须理解订单簿在内存里长什么样。我常用的数据结构是「价格-数量」映射表，配合一个排序的价位列。

最简单的实现方式：

# 订单簿的简化数据结构
class OrderBook:
    def __init__(self):
        self.bids = {}  # 价格 -> 数量
        self.asks = {}  # 价格 -> 数量
        self.bid_prices = []  # 降序排列
        self.ask_prices = []  # 升序排列
    
    def update(self, side, price, size):
        if side == 'bid':
            self.bids[price] = size
            self.bid_prices = sorted(self.bids.keys(), reverse=True)
        else:
            self.asks[price] = size
            self.ask_prices = sorted(self.asks.keys())

实际生产环境中，我们不会用Python的dict来做高频订单簿——太慢了。C++里一般用红黑树或者跳表，保证O(log n)的插入和查询。我曾经在项目中用Python硬扛高频数据，结果延迟飙到毫秒级，直接被CTO叫去喝茶了。

1.4 Level1 / Level2 / Level3 数据区别

这三个层级，说白了就是「你能看到多深」。我刚开始做交易时，以为Level1就够了，后来才发现——你看到的只是冰山一角。

Level1（第一层级）：只显示最佳买卖价和成交量。也就是上面表格里的10.03和10.04这两档。散户用的行情软件基本都是Level1。

Level2（第二层级）：显示多档买卖盘口。比如能看到10.01到10.05共5档，甚至50档。做量化策略，至少得用Level2数据。我个人习惯看10档深度，太深了反而噪音多。

Level3（第三层级）：能看到每个订单的详细信息，包括订单ID、下单时间、隐藏订单等。这是交易所内部或者做市商才能拿到的数据。普通散户别想了，门槛极高。

为什么会有这种区别？你想想看，如果所有人都能看到完整的订单簿，那大户的意图就完全暴露了。交易所为了保护大资金，只公开部分信息。

1.5 知识体系总览

下面这张图，是我自己整理的订单簿知识框架。你可以把它当作本章的思维导图：

这张图把本章的核心内容串起来了。从左到右，从上到下，分别是订单类型、盘口结构、数据存储、数据层级。我个人建议你把这四个维度都吃透，后面讲订单簿动态分析时，这些就是基本功。

---

公众号:蓝海数据掘金营，微信deep3321