谁应该先成交？
把买卖单放进同一条确定性队列，观察价格优先、时间优先、静止订单价格和部分成交。
- 按价格优先、时间优先解释订单队列
- 判断一笔大单为什么会部分成交
- 区分限价、成交价与撤单释放的冻结资产
- 上一章课程开始
- 本章谁应该先成交？
把买卖单放进同一条确定性队列，观察价格优先、时间优先、静止订单价格和部分成交。
- 下一章市价单会吃掉什么？
先想一想这几个问题
展开答案前，可以先在心里做个判断。与预期不同的内容可以加入复习列表。
Q01我最先下单，为什么别人还是先成交？＋
时间优先只在同一价格档位内生效。别人若给出更好的价格，会先越过你；即使同价，大单也可能先只成交一部分，剩余继续排队。
订单簿不是一个“把价格排序”的表格，而是一条需要在每次状态变化后仍然可验证的队列。撮合引擎要决定谁先成交、成交多少、用什么价格，以及剩余资产应该继续等待还是被释放。
先读懂买一和卖一
实验室的交易对是虚拟的 LAB / 积分。卖单按价格从低到高排，买单按价格从高到低排：
- 卖一（best ask）：当前最低的卖价。
- 买一（best bid）：当前最高的买价。
- 价差（spread）：卖一减去买一，代表立即成交要跨过的空间。
只要买一低于卖一，订单簿就没有交叉，撮合引擎会停在这里。新订单可以排队，也可以把自己的限价带进盘口，让买价大于等于卖价，从而触发撮合。
LAB / 积分
限价订单先进入队列；只有盘口交叉，撮合引擎才会把它们变成成交。
先读盘口：卖一是当前最低卖价，买一是当前最高买价。只有买价不低于卖价时，撮合循环才会启动。
- 01
盘口创建：卖一 102 分（两个价位相同的订单），买一 98 分。价格和时间都需要被保留。
拖动滑块可以回到此前的步骤。从那里继续操作时，后续记录会替换为新的操作序列。
价格优先之后，才轮到时间优先
盘口里有两个卖单都在 102 分：Maker A 先挂 2 LAB，Maker B 后挂 3 LAB。你提交买入 6 LAB @104 后，系统不会把它们随机打散，而是先成交 A 的 2，再成交 B 的 3。
这就是价格优先、时间优先：先选更有利的价格；同一价格再选更早进入队列的订单。排序必须稳定，事件日志也必须保留序号，否则相同输入可能产生不同余额和不同的结算结果。
一笔大单不一定一次成交完
你买入 6 LAB @104，但盘口只有 5 LAB 的卖单价格不超过 104：两个 102 分订单共 5 LAB。引擎会生成两条成交记录，剩余 1 LAB 继续以 104 分挂在买方队列。
部分成交非常重要，因为它把“订单意图”和“成交事实”分开了：原订单数量是 6，已成交数量是 5，剩余数量是 1。撤销时只能释放那 1 份对应的冻结积分，不能改写已经发生的成交。
展开：这一步如何实现
while bestBid.price >= bestAsk.price:
quantity = min(bestBid.remaining, bestAsk.remaining)
maker = earlier(bestBid, bestAsk)
price = maker.price
settle(buyer, seller, price, quantity)
bestBid.remaining -= quantity
bestAsk.remaining -= quantity
append(trade, price, quantity, maker)
生产系统还会加入自成交保护、最小价格变动、撮合批次、风控限额和断路器。教学内核只保留最小规则，但每个规则都能在状态、事件和不变量里找到对应证据。
实验室也会阻止一个账户用自己的买单和卖单互相成交：新进入的那张订单会被取消，冻结资产随之释放。不同交易所会提供不同的自成交保护模式，但“不能把自己的报价伪装成真实市场需求”是一个重要的边界。
队列规则也是一种公平性设计
价格时间优先并不是自然法则，而是一种市场设计选择。它让参与者知道“更好的价格、同价位更早的时间”会获得优先权；另一种设计也可能采用按比例分配、批量拍卖或随机排序。
当你比较订单簿和 AMM 时，差异不只是界面不同：订单簿把流动性拆在一个个等待中的订单里，AMM 把报价写进曲线。前者需要队列和撮合，后者需要储备和不变量。
为什么你提交买入 6 LAB @104 后，只成交 5 LAB，剩下 1 LAB 继续挂在 104？
用五个问题检查一个撮合引擎
走完实验后，试着解释：
- 当前买一、卖一和价差是多少？
- 两个同价订单为什么有先后？
- 成交价为什么来自静止订单，而不是新订单的限价？
- 部分成交后，订单、余额和冻结资产分别如何变化？
- 撤单为什么只能改变未来状态，不能抹掉历史成交？
这些问题是中心化交易所、链上订单簿和预测市场共享的骨架。理解它们之后，再研究批量拍卖、MEV 或清算，会有一套可以反复验证的状态语言。