一、订单簿基础：什么是订单簿、限价单与市价单、买卖盘口与深度图、做市商与流动性
大家好，我是你们的老朋友。今天咱们来聊聊链上订单簿模拟技术的第一章——订单簿基础。说实话，我在DeFi圈摸爬滚打这几年，见过太多人一上来就冲进流动性池子，结果被无常损失搞得头破血流。其实啊，订单簿才是传统金融和链上交易最核心的东西。你想想看，没有订单簿，你怎么知道现在市场上谁想买、谁想卖？价格又凭什么波动？
1.1 什么是订单簿？
订单簿，说白了就是一个「买卖挂单的账本」。它记录了所有交易者挂出的买入和卖出指令。我习惯把它想象成一个菜市场——卖菜的摊主喊价，买菜的顾客还价，双方达成一致就成交。订单簿就是那个记录所有喊价和还价的「黑板」。
在链上环境中，订单簿通常由智能合约维护。每个订单包含几个关键字段：
- 订单ID：唯一标识
- 交易对：比如ETH/USDC
- 方向：买单还是卖单
- 价格：你愿意买入或卖出的价格
- 数量：你要交易的数量
- 时间戳：挂单时间
- 状态：活跃、已成交、已取消
核心要点：订单簿的本质是一个「价格-数量」的映射关系。买单从高到低排列，卖单从低到高排列。中间那个交叉点，就是当前的市场价格。
我在做第一个链上订单簿项目时，犯过一个低级错误——把订单按时间排序而不是按价格排序。结果呢？一个高价的买单永远排在低价买单后面，用户直接骂娘。嗯，从那以后我再也不敢忽略排序逻辑了。
1.2 限价单与市价单
这两种订单类型，是交易的基础操作。我建议你先把它们刻在脑子里。
限价单（Limit Order）
限价单就是你指定一个价格，只有市场价格达到这个价格时才会成交。比如你挂一个「买入1 ETH，价格2000 USDC」，那只有当ETH跌到2000或以下时，你的单子才会被吃掉。
限价单的特点：
- 价格可控，但成交时间不确定
- 适合做波段或挂单做市
- 在链上需要支付Gas费，即使未成交也要付
市价单（Market Order）
市价单就是「不管价格多少，我现在就要成交」。你输入数量，系统自动按当前最优价格成交。说白了就是「梭哈」模式。
市价单的特点：
- 成交速度快，但价格可能滑点
- 适合紧急买入或卖出
- 在链上会吃掉订单簿中的流动性
我的经验：在链上做市价单时，一定要设置滑点保护。我曾经见过一个用户，在Uniswap V3上做市价单，结果因为流动性不足，滑点高达15%，直接亏掉了一台MacBook Pro。所以啊，市价单虽好，可不要贪杯。
1.3 买卖盘口与深度图
买卖盘口（Order Book）分为两个部分：
- 买盘（Bids）：所有买单的集合，从高到低排列
- 卖盘（Asks）：所有卖单的集合，从低到高排列
深度图（Depth Chart）就是把买卖盘口可视化。横轴是价格，纵轴是累计数量。买盘形成一条从左下到右上的曲线，卖盘形成一条从左上到右下的曲线。两条曲线之间的「缺口」，就是当前的市场价格区间。
为什么会这样？因为买单越便宜，愿意买的人越多；卖单越贵，愿意卖的人越少。这个逻辑很直观吧？
下面我用SVG画一张深度图的示意图，帮你理解：
你看这张图，绿色区域是买盘深度，红色区域是卖盘深度。中间那条橙色虚线就是当前市场价格。如果买盘区域比卖盘区域厚实，说明买方力量强，价格可能上涨。反之亦然。
注意：链上的深度图和中心化交易所的深度图有一个本质区别——链上深度图是「快照」式的，只反映某个区块时刻的状态。而中心化交易所的深度图是实时更新的。所以做链上交易时，一定要考虑「区块延迟」带来的影响。
1.4 做市商与流动性
做市商（Market Maker）是订单簿的「血液」。他们通过同时挂出买单和卖单，为市场提供流动性。说白了，做市商就是「赚差价」的——低价买入，高价卖出，赚取买卖价差（Spread）。
流动性（Liquidity）则是指市场在不影响价格的情况下，能够承载多大交易量。流动性越高，你的大额订单就越不容易造成价格剧烈波动。
我举个例子：
| 流动性水平 | 特点 | 典型场景 |
|---|---|---|
| 高流动性 | 买卖盘口厚实，滑点小 | ETH/USDC 主流交易对 |
| 中流动性 | 有一定深度，但大单会滑点 | 一些二线代币 |
| 低流动性 | 盘口很薄，大单直接砸穿 | 新发行的土狗币 |
在链上做市，和中心化交易所完全不同。中心化交易所的做市商可以用高频交易算法，毫秒级调整报价。但在链上，你每挂一个单都要付Gas费，而且交易确认需要时间。所以链上做市商更倾向于「被动做市」——挂好单子，等别人来吃。
避坑指南：我曾经在一条新公链上部署做市机器人，结果因为Gas价格波动太大，我的买单和卖单之间出现了「价格倒挂」——买单价格比卖单还高。这意味着每成交一笔我就亏一笔。嗯，从那以后我学会了在链上做市时必须设置「最小价差保护」。
1.5 链上订单簿的核心数据结构
作为一个Solidity开发者，我习惯用结构体来表示订单。下面是一个简化版的订单数据结构：
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
struct Order {
address trader; // 交易者地址
bool isBuy; // true=买单, false=卖单
uint256 price; // 价格（以最小单位计）
uint256 amount; // 数量
uint256 filled; // 已成交数量
uint256 timestamp; // 挂单时间
bool isActive; // 是否活跃
}
// 订单簿存储
mapping(uint256 => Order) public orders;
uint256 public orderCount;
// 按价格排序的订单ID列表（使用红黑树或排序数组）
uint256[] public buyOrderIds; // 从高到低
uint256[] public sellOrderIds; // 从低到高你可能会问：为什么不用mapping直接存？因为我们需要按价格排序。在Solidity里，排序是个麻烦事。我建议用「排序数组+二分查找」的方式，或者直接引入一个排序库（比如OpenZeppelin的SortedArray）。
不过说实话，链上订单簿最大的挑战不是数据结构，而是Gas优化。每插入一个订单都要排序，如果订单量大了，Gas费会高得离谱。这也是为什么很多DeFi项目选择用「AMM（自动做市商）」而不是传统订单簿的原因之一。
1.6 小结
好了，这一章的内容就到这里。订单簿是交易的基础设施，理解它你才能理解后面的模拟技术。限价单和市价单是两种最基本的交易指令，买卖盘口和深度图帮你读懂市场情绪，做市商和流动性则是市场的「润滑剂」。
我个人觉得，学订单簿最好的方法就是自己动手写一个。哪怕是最简单的版本，也能让你深刻理解其中的坑。下一章我们会深入链上订单簿的撮合引擎实现，到时候我会带你们手写一个完整的撮合合约。
记住：纸上得来终觉浅，绝知此事要躬行。
公众号:蓝海资料掘金营，微信deep3321