11 · 撮合引擎原理：订单怎么变成成交

交易系统里最核心、最不该出错的环节，不是下单、不是行情，而是撮合——买卖双方怎么配对、按什么规则排队、谁先成交。普通交易者只需要知道「价格优先、时间优先」八个字，而做系统的工程师需要把八个字展开成数据结构、算法与工程约束。

本篇从撮合的定义讲起，覆盖撮合规则、订单簿数据结构、撮合算法、高级话题（做市、涨跌停排队、大宗、闪电崩盘）、交易所撮合 vs 区块链 AMM 的对比，最后是撮合引擎的设计要点。

1. 撮合是什么

撮合（Matching）是把买单与卖单按规则配对并确定成交价、成交量的过程。无论哪个市场，撮合的本质都是同一个问题：

给定当前订单簿（所有未成交**限价单**）与一个新进来的订单，怎么生成一组「成交」？

text

新买单（买 100 手 @ 4100）──▶ 撮合引擎 ──▶ 成交记录：卖一 4100 成交 50 手
                                  │        卖二 4101 成交 50 手
                                  └──▶ 剩余 0 手（全部成交）

概念	定义
订单簿（Order Book）	所有未成交限价单按价格组织的队列集合
撮合引擎（Matching Engine）	执行撮合规则的软件/系统，交易所的最核心资产
成交（Fill/Trade）	一笔买单与一笔卖单配对成功，产生价格与数量
剩余量（Leaves）	成交后订单未成交的部分，继续留在订单簿排队

撮合引擎的职责边界是「合法地、可复现地把订单变成成交」——它不决定价格涨跌，只决定谁先成交、以什么价成交。做市、报价、定价是市场参与者的事，撮合引擎只是规则的执行者。

2. 撮合规则：价格优先、时间优先

2.1 两条铁律

连续竞价（Continuous Trading）的核心规则，全世界统一：

规则	内容	通俗说法
价格优先	买单：出价高的先成交；卖单：出价低的先成交	谁给的价格好，谁先走
时间优先	同一价格：先挂单的先成交	同价先到先得

一个直观例子（当前订单簿）：

档位	卖单
卖一	4101 × 100
卖二	4102 × 200

买入限价单 4101 × 150：与卖一（4101）成交 100 手，剩 50 手与卖二（4102）成交 50 手——成交价分别为 4101、4102，全部成交。
买入限价单 4100 × 50：价格低于卖一（4101），无法立即成交 → 进入买单队列排在 4100 价位，等价格跌下来。
买入市价单 × 100：直接吃卖一 4101×100，成交价 4101——市价单 = 不限价、以对手方最优价立即成交。

2.2 限价单与市价单在撮合队列中的位置

订单类型	进入队列吗？	在队列中的位置
限价单（未成交部分）	进入订单簿	按价格归档；同价按时间戳排在队尾（时间优先）
市价单	不进入订单簿	只存在于「入场瞬间」，立即与对手方最优价撮合；不能立即全部成交的剩余部分按交易所规则处理（部分转为限价/直接撤销，以交易所规则为准）

由此推出一个工程常识：市价单是「抢」，限价单是「排队」。限价单想保证成交，挂单价格要越过对手方最优价（即高于卖一/低于买一）；同价排队则完全拼时间。

3. 订单簿数据结构

3.1 Level-2 盘口

交易所行情中最常见的数据结构：买一~~买五、卖一~~卖五（深度按交易所而定，加密所常见 20-100 档）。

档位	含义	数据内容
买一	当前最高的未成交买单价格	价格 + 该价总挂单量
买二~买五	依次更低的买价	同上
卖一	当前最低的未成交卖单价格	价格 + 该价总挂单量
卖二~卖五	依次更高的卖价	同上

盘口三个关键含义：

买一与卖一之差 = 点差（Spread），是**流动性**质量的直接度量；买一价就是「想立即卖出的参考价」，卖一价是「想立即买入的参考价」。
盘口是聚合视图（每个价位上的总量），看不到队列里的每一笔单——真正的逐笔队列属于内部数据。
盘口数量含冰山单隐藏部分？不含——冰山单只暴露一部分，聚合视图只能看到暴露量（以交易所规则为准）。

3.2 增量更新（add / update / delete 事件）

行情对接与撮合引擎内部都用事件模型描述订单簿变化：

事件	语义	例子
add	新价档出现	4101 价位首次出现挂单
update	某价位数量变化	4101 从 100 手变 80 手（部分成交/加单）
delete	某价位清空	4101 数量归零，档位消失

客户端按事件流重建/维护本地订单簿；事件必须带序列号（Sequence），用于乱序检测与断线补缺口。
国内 CTP 行情以「五档快照」为主（无增量事件序列，直接推最新五档）；加密交易所 WebSocket 的 depth 频道则是标准的增量事件流（depthUpdate 事件带价格+数量，数量 0 即 delete）。

3.3 订单簿重建（Rebuild）

增量事件流的致命弱点是「丢一个事件就整体错位」：一个 update 丢失，本地盘口从此与真实盘口永久偏差。因此：

任何深度频道都必须提供重建机制：检测到序号缺口/断线重连后，请求全量快照（REST 拉取 depth snapshot），再叠加之后的增量。
重建流程的经典三步：拉全量快照 → 记录快照对应的最后序号 → 丢弃序号 ≤ 该值的存量增量，仅应用更新的增量。
重建期间，基于盘口的策略必须暂停——拿错误的盘口下单比不下单更危险。

💀 重建期间基于盘口的策略必须暂停

重建期间，基于盘口的策略必须暂停——拿错误的盘口下单比不下单更危险。 增量事件流丢一个 update，本地盘口从此与真实盘口永久偏差；此时若策略仍按「错位盘口」报单或对冲，错的位置、错的量，全部变成实盘损失。

4. 撮合算法

4.1 简单匹配循环（限价单入场）

最朴素的核心逻辑（任何撮合引擎的雏形）：

text

输入：新订单（方向、价格、数量）
对手方队列 = 买单则看卖队列，卖单则看买队列（按价格优先排序，头端最优）

while 新订单还有剩余量 且 对手方队列非空 且 价格可成交（买价 ≥ 卖价）:
    头端订单 = 对手方队列头（最优价、最早时间）
    成交价 = 头端订单价格           # 挂单者的限价，而非新订单的限价
    成交量 = min(新订单剩余量, 头端订单剩余量)
    生成成交记录；双方剩余量各自扣减
    若头端订单剩余量为 0：从队列移除（并可能触发 delete 事件）

若新订单还有剩余量：
    若为限价单：加入本方队列（同价插到队尾，时间优先）
    若为市价单：按规则处理剩余（部分转限价/撤销）

一个关键细节：成交价始终是「队列里先挂者」的限价。新单以更优价格吃单时，成交价按对手方挂单价成交——这就是「限价单给你更好的价格」的原因，也是**滑点**分析的基础。

💀 增量事件流丢一个事件整体就永久错位

增量事件流的致命弱点是「丢一个事件就整体错位」：一个 update 丢失，本地盘口从此与真实盘口永久偏差。 重建流程的经典三步：拉全量快照 → 记录快照对应的最后序号 → 丢弃序号 ≤ 该值的存量增量，仅应用更新的增量。重建期间基于盘口的策略必须暂停——拿错误的盘口下单比不下单更危险。

4.2 连续竞价撮合（伪代码）

把 4.1 放在交易所真实约束下（以连续竞价时段为例）：

text

while 收到新订单:
    校验（价格步进、数量、风控）→ 不通过则拒绝，返回 REJECTED
    执行匹配循环（见 4.1）
    输出事件：OrderUpdate（订单状态变化）、Trade（成交）、DepthUpdate（盘口变化）
    事件按全局递增序号广播 → 落盘为不可变事件日志

关键约束：

先校验后撮合：非法订单（价格越限、数量不合规）直接拒单，不进入撮合。
事件顺序全局唯一：所有订阅方看到的事件序号一致——这是「行情一致性」的保证（详见 03-行情系统.md）。

💡 先校验后撮合先事件日志后广播

先校验后撮合：非法订单（价格越限、数量不合规）直接拒单，不进入撮合。撮合结果必须先写日志（WAL）再对外广播——事件日志是「顺序、不可变、可重放」的，它是行情广播、对账、审计、故障恢复的唯一事实来源。

确定性：同样的订单序列、同样的时间戳，撮合结果必须完全一致——这是回放（Replay）与对账的基础。

4.3 集合竞价（开盘/收盘：最大成交量定价）

连续竞价是「逐笔撮合」，集合竞价是「一批集中撮合」，核心原则是最大成交量定价：

text

1. 收集阶段（如 A 股 9:15-9:25）：接受委托，不撮合
2. 定价阶段：
   对所有买单/卖单按价格排序，尝试每个候选价
   找出「可成交数量最大」的价格区间（最大成交量原则）
   存在多个候选价时，取「偏离昨收价最近」的（次规则以交易所规则为准）
3. 撮合：所有满足「买价 ≥ 开盘价 ≥ 卖价」的订单按开盘价成交；同价按时间优先
4. 未成交部分进入连续竞价（或撤销，按规则）

开盘价：由集合竞价产生，是「把最多订单成交掉的价格」——真实市场里开盘价的确定就这样朴素。
对工程的意义：集合竞价期间不允许市价类委托、报单行为与连续竞价不同（以各交易所规则为准）；收盘集合竞价同理（A 股 14:57-15:00）。

5. 高级话题

5.1 做市商与最小报价单位

最小报价单位（Tick Size）：价格必须落在最小步进的网格上（如螺纹钢 1 元/吨、加密 BTC 以 0.1 或 0.01 计），撮合引擎按网格校验与组织队列。
做市商：报价方，双边挂单赚点差；撮合引擎对做市商订单可能有独立队列（指定做市商优先级）与激励，但核心仍遵循价格/时间优先（特殊规则以交易所规定为准）。

5.2 涨跌停时的排队

涨跌停时，排队的意义完全不同：

涨停板：卖单没人接，买单全部排队等卖单出现——排队顺序 = 时间优先（先挂的先成交），此时「能不能成交」取决于你在买单队列里的位置，而非价格（价格都一样）。
跌停板：镜像对称。
对交易者的含义：涨停板上排队想卖出的人排在队列尾部，可能排几个交易日都轮不到；对系统的含义：排队位置就是一切，挂单时机比价格更重要。

5.3 大宗交易撮合（撮合外配对）

大宗交易：在连续竞价之外，买卖双方协商价格与数量后，向交易所申报，在专门的时段（如收盘后）按协商价成交。
性质：撮合外配对——交易所不参与价格发现，只做清算层面的确认与信息披露。
对工程的意义：大宗成交的回报、行情标识（特殊成交量标记）与普通成交不同，行情系统与对账系统要能区分。

5.4 闪电崩盘与撮合延迟

撮合引擎的延迟直接决定市场微观结构：延迟越低，抢跑窗口越窄；撮合排队（处理速度跟不上订单流）是高频故障形态之一。
闪电崩盘（Flash Crash）的典型机制：极端行情下市价单/止损单连环触发、流动性瞬间蒸发，盘口深度骤减导致价格在毫秒级暴跌后回弹——撮合引擎本身只是忠实地执行了规则，但引擎的流控与熔断机制（如波动性暂停）是防崩盘的工程手段（以各交易所规则为准）。

6. 交易所撮合 vs 区块链 AMM

6.1 中心化撮合（订单簿）回顾

特征	订单簿撮合（CEX / 期货 / 股票）
价格发现	订单簿供需决定
对手方	需要有人与你的订单配对
成交价	队列中先挂者的限价
流动性	取决于挂单者的参与

6.2 区块链 AMM（自动化做市商）

DeFi 里的 Uniswap 等协议用恒定乘积公式替代订单簿：

text

x * y = k

x = 池中代币 A 数量，y = 池中代币 B 数量，k 为恒定常数
买入 Δx 个 A：需支付 Δy 个 B，满足 (x - Δx) * (y + Δy) = k

特征	AMM（如 Uniswap）
价格发现	由池内两种资产的数量比例决定（无需订单簿）
对手方	流动性池（LP 存入的两侧资产）
成交价	随交易量滑动的公式价：你买得越多，价格越贵
流动性	池子深度即流动性，24×7 无休

6.3 滑点与无常损失

概念	定义	与订单簿市场的对照
滑点	实际成交价与期望价的偏差	订单簿里是「吃掉更多档位」；AMM 里是「公式定价随交易量变化」——同一笔交易越大，滑点越高
无常损失（Impermanent Loss）	LP 提供流动性的收益，与「直接持有两种代币」相比的差额损失：价格偏离存入时比例越大，损失越明显	订单簿市场没有直接对应物（做市商的风险是库存与点差，理念相近）

一句话对比：订单簿撮合是「人与人」配对的精确市场，AMM 是「人与公式」配对的确定性市场。前者需要流动性供给，后者用资金池恒定公式自动定价——效率、透明与无常损失是 AMM 的三大主题。

7. 撮合引擎设计要点

如果自己实现一个撮合引擎（模拟撮合/内部撮合器，不是真实交易所），要点如下：

7.1 内存订单簿

订单簿必须在内存：价格队列用平衡树/跳表/优先队列（价格有序）+ 每价位的 FIFO 队列（时间优先），撮合是纯内存操作。
性能目标常识：每笔撮合延迟微秒级（真实撮合引擎的指标在微秒到几十微秒量级，具体以实现与硬件为准）——任何磁盘 I/O、网络同步进撮合主循环都是不可接受的。
单线程处理订单流（无锁或少锁）：撮合逻辑的并发正确性靠「串行化订单流」保证，而不是靠锁。

7.2 事件日志（撮合记录不可丢）

撮合结果必须先写日志（WAL）再对外广播：事件日志是「顺序、不可变、可重放」的——它是行情广播、对账、审计、故障恢复的唯一事实来源。
日志落盘走顺序写（Append-Only），与撮合主循环解耦（异步批量刷盘）；崩溃恢复时从日志重放重建内存订单簿。
审计要求：撮合记录保留时长按监管要求执行，且不可篡改。

7.3 性能指标

指标	含义	参考常识
每笔撮合延迟	订单进引擎到成交事件产出	微秒级（µs）
撮合吞吐	每秒处理订单数	数万~数十万笔/秒（取决于实现）
事件到广播延迟	成交到订阅方可见	与网络/行情链路叠加（详见 03 篇）
可用性	引擎不宕机时间	交易时段内为目标 99.99%+

7.4 其余工程要点

价格/数量用整数或定点数（禁止浮点比较）——浮点误差在撮合里会变成「对不上的账」。
校验先行、风控前置；非法订单必须在进队列前拒绝。
模拟撮合器（自建 Mock）要能注入异常（拒单、乱序、断线），用于回归测试——这是 01-对接全景与角色分工.md 里「自建模拟柜台」的基础。

风险提示

⚠️ 风险提示

撮合引擎是交易系统中最不能「差不多就行」的组件：订单排序错误会让时间优先失效，浮点运算会让对账永远差一分钱，事件日志丢失会让回放与审计失去依据，而撮合逻辑与行情广播耦合则会把毫秒级故障放大成全局瘫痪。本文所述撮合规则、流控数值与性能指标均为行业通行口径，具体以各交易所规则与官方文档为准。若只是对接（而非自研撮合），请把注意力放在订单簿重建、事件序号与对账上——自研撮合引擎是大型工程，请勿在生产资金链路中直接投入使用。

交易系统里最核心、最不该出错的环节，不是下单、不是行情，而是撮合——买卖双方怎么配对、按什么规则排队、谁先成交。普通交易者只需要知道「价格优先、时间优先」八个字，而做系统的工程师需要把八个字展开成数据结构、算法与工程约束。

本篇从撮合的定义讲起，覆盖撮合规则、订单簿数据结构、撮合算法、高级话题（做市、涨跌停排队、大宗、闪电崩盘）、交易所撮合 vs 区块链 AMM 的对比，最后是撮合引擎的设计要点。

1. 撮合是什么

撮合（Matching）是把买单与卖单按规则配对并确定成交价、成交量的过程。无论哪个市场，撮合的本质都是同一个问题：

给定当前订单簿（所有未成交**限价单**）与一个新进来的订单，怎么生成一组「成交」？

text

新买单（买 100 手 @ 4100）──▶ 撮合引擎 ──▶ 成交记录：卖一 4100 成交 50 手
                                  │        卖二 4101 成交 50 手
                                  └──▶ 剩余 0 手（全部成交）

概念	定义
订单簿（Order Book）	所有未成交限价单按价格组织的队列集合
撮合引擎（Matching Engine）	执行撮合规则的软件/系统，交易所的最核心资产
成交（Fill/Trade）	一笔买单与一笔卖单配对成功，产生价格与数量
剩余量（Leaves）	成交后订单未成交的部分，继续留在订单簿排队

撮合引擎的职责边界是「合法地、可复现地把订单变成成交」——它不决定价格涨跌，只决定谁先成交、以什么价成交。做市、报价、定价是市场参与者的事，撮合引擎只是规则的执行者。

2. 撮合规则：价格优先、时间优先

2.1 两条铁律

连续竞价（Continuous Trading）的核心规则，全世界统一：

规则	内容	通俗说法
价格优先	买单：出价高的先成交；卖单：出价低的先成交	谁给的价格好，谁先走
时间优先	同一价格：先挂单的先成交	同价先到先得

一个直观例子（当前订单簿）：

档位	卖单
卖一	4101 × 100
卖二	4102 × 200

买入限价单 4101 × 150：与卖一（4101）成交 100 手，剩 50 手与卖二（4102）成交 50 手——成交价分别为 4101、4102，全部成交。
买入限价单 4100 × 50：价格低于卖一（4101），无法立即成交 → 进入买单队列排在 4100 价位，等价格跌下来。
买入市价单 × 100：直接吃卖一 4101×100，成交价 4101——市价单 = 不限价、以对手方最优价立即成交。

2.2 限价单与市价单在撮合队列中的位置

订单类型	进入队列吗？	在队列中的位置
限价单（未成交部分）	进入订单簿	按价格归档；同价按时间戳排在队尾（时间优先）
市价单	不进入订单簿	只存在于「入场瞬间」，立即与对手方最优价撮合；不能立即全部成交的剩余部分按交易所规则处理（部分转为限价/直接撤销，以交易所规则为准）

由此推出一个工程常识：市价单是「抢」，限价单是「排队」。限价单想保证成交，挂单价格要越过对手方最优价（即高于卖一/低于买一）；同价排队则完全拼时间。

3. 订单簿数据结构

3.1 Level-2 盘口

交易所行情中最常见的数据结构：买一~~买五、卖一~~卖五（深度按交易所而定，加密所常见 20-100 档）。

档位	含义	数据内容
买一	当前最高的未成交买单价格	价格 + 该价总挂单量
买二~买五	依次更低的买价	同上
卖一	当前最低的未成交卖单价格	价格 + 该价总挂单量
卖二~卖五	依次更高的卖价	同上

盘口三个关键含义：

买一与卖一之差 = 点差（Spread），是**流动性**质量的直接度量；买一价就是「想立即卖出的参考价」，卖一价是「想立即买入的参考价」。
盘口是聚合视图（每个价位上的总量），看不到队列里的每一笔单——真正的逐笔队列属于内部数据。
盘口数量含冰山单隐藏部分？不含——冰山单只暴露一部分，聚合视图只能看到暴露量（以交易所规则为准）。

3.2 增量更新（add / update / delete 事件）

行情对接与撮合引擎内部都用事件模型描述订单簿变化：

事件	语义	例子
add	新价档出现	4101 价位首次出现挂单
update	某价位数量变化	4101 从 100 手变 80 手（部分成交/加单）
delete	某价位清空	4101 数量归零，档位消失

客户端按事件流重建/维护本地订单簿；事件必须带序列号（Sequence），用于乱序检测与断线补缺口。
国内 CTP 行情以「五档快照」为主（无增量事件序列，直接推最新五档）；加密交易所 WebSocket 的 depth 频道则是标准的增量事件流（depthUpdate 事件带价格+数量，数量 0 即 delete）。

3.3 订单簿重建（Rebuild）

增量事件流的致命弱点是「丢一个事件就整体错位」：一个 update 丢失，本地盘口从此与真实盘口永久偏差。因此：

任何深度频道都必须提供重建机制：检测到序号缺口/断线重连后，请求全量快照（REST 拉取 depth snapshot），再叠加之后的增量。
重建流程的经典三步：拉全量快照 → 记录快照对应的最后序号 → 丢弃序号 ≤ 该值的存量增量，仅应用更新的增量。
重建期间，基于盘口的策略必须暂停——拿错误的盘口下单比不下单更危险。

💀 重建期间基于盘口的策略必须暂停

4. 撮合算法

4.1 简单匹配循环（限价单入场）

最朴素的核心逻辑（任何撮合引擎的雏形）：

text

输入：新订单（方向、价格、数量）
对手方队列 = 买单则看卖队列，卖单则看买队列（按价格优先排序，头端最优）

while 新订单还有剩余量 且 对手方队列非空 且 价格可成交（买价 ≥ 卖价）:
    头端订单 = 对手方队列头（最优价、最早时间）
    成交价 = 头端订单价格           # 挂单者的限价，而非新订单的限价
    成交量 = min(新订单剩余量, 头端订单剩余量)
    生成成交记录；双方剩余量各自扣减
    若头端订单剩余量为 0：从队列移除（并可能触发 delete 事件）

若新订单还有剩余量：
    若为限价单：加入本方队列（同价插到队尾，时间优先）
    若为市价单：按规则处理剩余（部分转限价/撤销）

一个关键细节：成交价始终是「队列里先挂者」的限价。新单以更优价格吃单时，成交价按对手方挂单价成交——这就是「限价单给你更好的价格」的原因，也是**滑点**分析的基础。

💀 增量事件流丢一个事件整体就永久错位

4.2 连续竞价撮合（伪代码）

把 4.1 放在交易所真实约束下（以连续竞价时段为例）：

text

while 收到新订单:
    校验（价格步进、数量、风控）→ 不通过则拒绝，返回 REJECTED
    执行匹配循环（见 4.1）
    输出事件：OrderUpdate（订单状态变化）、Trade（成交）、DepthUpdate（盘口变化）
    事件按全局递增序号广播 → 落盘为不可变事件日志

关键约束：

先校验后撮合：非法订单（价格越限、数量不合规）直接拒单，不进入撮合。
事件顺序全局唯一：所有订阅方看到的事件序号一致——这是「行情一致性」的保证（详见 03-行情系统.md）。

💡 先校验后撮合先事件日志后广播

确定性：同样的订单序列、同样的时间戳，撮合结果必须完全一致——这是回放（Replay）与对账的基础。

4.3 集合竞价（开盘/收盘：最大成交量定价）

连续竞价是「逐笔撮合」，集合竞价是「一批集中撮合」，核心原则是最大成交量定价：

text

1. 收集阶段（如 A 股 9:15-9:25）：接受委托，不撮合
2. 定价阶段：
   对所有买单/卖单按价格排序，尝试每个候选价
   找出「可成交数量最大」的价格区间（最大成交量原则）
   存在多个候选价时，取「偏离昨收价最近」的（次规则以交易所规则为准）
3. 撮合：所有满足「买价 ≥ 开盘价 ≥ 卖价」的订单按开盘价成交；同价按时间优先
4. 未成交部分进入连续竞价（或撤销，按规则）

开盘价：由集合竞价产生，是「把最多订单成交掉的价格」——真实市场里开盘价的确定就这样朴素。
对工程的意义：集合竞价期间不允许市价类委托、报单行为与连续竞价不同（以各交易所规则为准）；收盘集合竞价同理（A 股 14:57-15:00）。

5. 高级话题

5.1 做市商与最小报价单位

最小报价单位（Tick Size）：价格必须落在最小步进的网格上（如螺纹钢 1 元/吨、加密 BTC 以 0.1 或 0.01 计），撮合引擎按网格校验与组织队列。
做市商：报价方，双边挂单赚点差；撮合引擎对做市商订单可能有独立队列（指定做市商优先级）与激励，但核心仍遵循价格/时间优先（特殊规则以交易所规定为准）。

5.2 涨跌停时的排队

涨跌停时，排队的意义完全不同：

涨停板：卖单没人接，买单全部排队等卖单出现——排队顺序 = 时间优先（先挂的先成交），此时「能不能成交」取决于你在买单队列里的位置，而非价格（价格都一样）。
跌停板：镜像对称。
对交易者的含义：涨停板上排队想卖出的人排在队列尾部，可能排几个交易日都轮不到；对系统的含义：排队位置就是一切，挂单时机比价格更重要。

5.3 大宗交易撮合（撮合外配对）

大宗交易：在连续竞价之外，买卖双方协商价格与数量后，向交易所申报，在专门的时段（如收盘后）按协商价成交。
性质：撮合外配对——交易所不参与价格发现，只做清算层面的确认与信息披露。
对工程的意义：大宗成交的回报、行情标识（特殊成交量标记）与普通成交不同，行情系统与对账系统要能区分。

5.4 闪电崩盘与撮合延迟

撮合引擎的延迟直接决定市场微观结构：延迟越低，抢跑窗口越窄；撮合排队（处理速度跟不上订单流）是高频故障形态之一。
闪电崩盘（Flash Crash）的典型机制：极端行情下市价单/止损单连环触发、流动性瞬间蒸发，盘口深度骤减导致价格在毫秒级暴跌后回弹——撮合引擎本身只是忠实地执行了规则，但引擎的流控与熔断机制（如波动性暂停）是防崩盘的工程手段（以各交易所规则为准）。

6. 交易所撮合 vs 区块链 AMM

6.1 中心化撮合（订单簿）回顾

特征	订单簿撮合（CEX / 期货 / 股票）
价格发现	订单簿供需决定
对手方	需要有人与你的订单配对
成交价	队列中先挂者的限价
流动性	取决于挂单者的参与

6.2 区块链 AMM（自动化做市商）

DeFi 里的 Uniswap 等协议用恒定乘积公式替代订单簿：

text

x * y = k

x = 池中代币 A 数量，y = 池中代币 B 数量，k 为恒定常数
买入 Δx 个 A：需支付 Δy 个 B，满足 (x - Δx) * (y + Δy) = k

特征	AMM（如 Uniswap）
价格发现	由池内两种资产的数量比例决定（无需订单簿）
对手方	流动性池（LP 存入的两侧资产）
成交价	随交易量滑动的公式价：你买得越多，价格越贵
流动性	池子深度即流动性，24×7 无休

6.3 滑点与无常损失

概念	定义	与订单簿市场的对照
滑点	实际成交价与期望价的偏差	订单簿里是「吃掉更多档位」；AMM 里是「公式定价随交易量变化」——同一笔交易越大，滑点越高
无常损失（Impermanent Loss）	LP 提供流动性的收益，与「直接持有两种代币」相比的差额损失：价格偏离存入时比例越大，损失越明显	订单簿市场没有直接对应物（做市商的风险是库存与点差，理念相近）

一句话对比：订单簿撮合是「人与人」配对的精确市场，AMM 是「人与公式」配对的确定性市场。前者需要流动性供给，后者用资金池恒定公式自动定价——效率、透明与无常损失是 AMM 的三大主题。

7. 撮合引擎设计要点

如果自己实现一个撮合引擎（模拟撮合/内部撮合器，不是真实交易所），要点如下：

7.1 内存订单簿

订单簿必须在内存：价格队列用平衡树/跳表/优先队列（价格有序）+ 每价位的 FIFO 队列（时间优先），撮合是纯内存操作。
性能目标常识：每笔撮合延迟微秒级（真实撮合引擎的指标在微秒到几十微秒量级，具体以实现与硬件为准）——任何磁盘 I/O、网络同步进撮合主循环都是不可接受的。
单线程处理订单流（无锁或少锁）：撮合逻辑的并发正确性靠「串行化订单流」保证，而不是靠锁。

7.2 事件日志（撮合记录不可丢）

撮合结果必须先写日志（WAL）再对外广播：事件日志是「顺序、不可变、可重放」的——它是行情广播、对账、审计、故障恢复的唯一事实来源。
日志落盘走顺序写（Append-Only），与撮合主循环解耦（异步批量刷盘）；崩溃恢复时从日志重放重建内存订单簿。
审计要求：撮合记录保留时长按监管要求执行，且不可篡改。

7.3 性能指标

指标	含义	参考常识
每笔撮合延迟	订单进引擎到成交事件产出	微秒级（µs）
撮合吞吐	每秒处理订单数	数万~数十万笔/秒（取决于实现）
事件到广播延迟	成交到订阅方可见	与网络/行情链路叠加（详见 03 篇）
可用性	引擎不宕机时间	交易时段内为目标 99.99%+

7.4 其余工程要点

价格/数量用整数或定点数（禁止浮点比较）——浮点误差在撮合里会变成「对不上的账」。
校验先行、风控前置；非法订单必须在进队列前拒绝。
模拟撮合器（自建 Mock）要能注入异常（拒单、乱序、断线），用于回归测试——这是 01-对接全景与角色分工.md 里「自建模拟柜台」的基础。

风险提示

⚠️ 风险提示