作者： danny
打开 Binance 现货和永续，订单簿几乎一模一样。但在"卖出"的瞬间，背后是两个根本不同的状态机。为什么 perp 要维护两套价格？为什么 Iron Condor 必须四条腿一起成交？为什么 Polymarket 的手续费在 p=0.5 时最贵？为什么 Uniswap 的 LP 永远跑输持有？这些问题表面在问机制，本质在问同一件事——撮合引擎从来不是独立的工程模块，它是被它服务的资产塑造出来的。
现货、永续、期权、Polymarket、AMM 五种形态之间的差异远比相似更深。这篇文章把它们拆开，看清是什么力量让"撮合"分化成几乎不相关的工程实体。
一、撮合不是标准件
如果你只看过现货交易的撮合实现，可能会觉得"撮合引擎"是一类成熟、收敛、几乎没什么技术含量的事情——一个排序的订单簿、一个价格时间优先的匹配循环、加上一个一次性结算路径，end of the story。
那你就大错特错了。。。
当你把视角从 Coinbase 的 BTC/USDT 拉到 Binance 的 BTCUSDT 永续合约，再拉到 Deribit 的 BTC-26DEC25-50000-C，最后落到 Polymarket 上某个事件市场，你会发现这四个市场背后的撮合引擎在结构上几乎是四种不同的机器。它们共享某种算法上的相似性——都有买方、卖方、价格、数量——但当你深入到状态机、风控耦合、事务边界、信任假设这些层面，差别大到让"撮合引擎"这个词本身显得过于抽象。
这篇文章想做的，是把这四种典型形态拆开，看清是什么力量让同一个底层概念在不同标的下分化成不同的工程实体。
二、现货撮合：最基础的形态
现货撮合是一个标准模型，几乎所有教科书和开源项目（LMAX Disruptor、CME Globex 的简化版、各类开源 matching engine）都从这里开始。
核心数据结构通常是两棵价格树（bid 侧、ask 侧），每个价格节点挂一条 FIFO 队列。撮合循环非常直接：当一个吃单（taker）到达，从对手方的最优价格档位开始扫描，按时间顺序消耗 maker 队列，直到吃单数量耗尽或价格越过限价。
核心特征有几个关键点值得专门拎出来：
第一，资产是同质且可分离的。买方持有 quote 资产（USDT），卖方持有 base 资产（BTC），撮合的本质就是一次资产置换。账本上的操作是一对绑定在事务里的余额加减，结算和撮合在同一个事务内完成。撮合引擎几乎不需要外部依赖——撮合即结算，没有下游链路。
第二，风险是即时清零的。一笔现货交易完成的瞬间，所有头寸关系就消失了，不存在"持仓"这个概念在撮合层面的延续。引擎不需要关心你下一秒会不会因为价格波动而爆仓，因为根本没有"仓位"这回事。
第三，订单类型相对收敛。Limit、Market、IOC、FOK、Post-only、Stop——这些都是订单生命周期管理上的变体。
举一个具体场景。BTC/USDT 卖一档 50,001 × 1.5 BTC（maker A 在 09:30:00.100 挂单），卖二档 50,002 × 3.0 BTC（maker B 在 09:30:00.200 挂 1.0，maker C 在 09:30:00.300 挂 2.0）。一笔 4.0 BTC 的市价买单到达。撮合循环：先吃 A 全部 1.5 @ 50,001，然后到下一档按 FIFO 顺序——B 先于 C，先吃 B 全部 1.0 @ 50,002，再吃 C 部分 1.5（C 剩 0.5 留簿）。Taker 账户在同一事务里扣减 200,006.5 USDT、增加 4.0 BTC，三个 maker 账户对应反向更新。这一连串操作在一个数据库事务里完成，撮合即结算。值得注意的是 B 先于 C 成交不是因为价格（同档），是因为先挂——这就是 price-time priority 的实际体现。
现货撮合工程上的难点其实不在逻辑，而在性能：如何在百万级 TPS 下保持微秒级延迟，如何处理冷热路径的 cache locality，如何做到 deterministic replay。但这些是优化问题，不是机制问题。
三、永续合约撮合：风控引擎的入侵
如果你把 Binance 永续合约的订单簿截图放在现货订单簿旁边，肉眼可能看不出区别。但底层就是另一个风景了。
关键变化在于：撮合引擎不是结算的终点，只是一个事件源。（aka 一个多米诺骨牌）
每一笔 perp 撮合的完成都触发一条复杂的下游链路：标记价格更新、仓位更新、保证金重算、未实现盈亏刷新、可能的强平触发。撮合引擎和风险引擎在 perp 这里是深度耦合的，耦合方式决定了整个系统的性格。
双价格体系是 perp 的第一个独特结构。撮合本身依然按"最新成交价"驱动（last traded price），但维持保证金、强平触发、UPnL 计算用的是"标记价格"（mark price），后者是多个现货市场的指数加上 funding adjustment 合成出来的。这是一个反操纵设计：如果撮合价和标记价合一，攻击者可以用一笔小资金把订单簿拉到某个极端价格，瞬间引爆所有反向仓位的强平。双轨制把这个攻击面消灭了。
举一个具体场景说明双价格的作用。某交易者 50x 多 1 BTC，入场 60,000，初始保证金 1,200 USDT，维持保证金 300 USDT。某一时刻订单簿被一笔大额市价单瞬间打穿到 last price = 58,500——按 last 算未实现亏损 1,500 USDT，已经穿仓。但同一时刻 mark price（多现货指数加权 + funding adj）= 59,400，按 mark 算未实现亏损 600 USDT，账户净值 600 > 维持保证金 300，强平不触发。几秒后 last price 回归 59,400，这位交易者没有被插针毛刺扫掉。如果撮合和强平共用 last price，攻击者用一笔小资金在订单簿薄弱时刻把价格拉到极端位置，就能触发反向仓位连环爆仓再低价吃回——这正是 BitMEX 早期频繁发生的事件类型。双轨制不是"为了精确"，是"为了不被攻击"。
Pre-trade 风控是另一个关键插入点。在现货里，吃单到达就直接撮合；在 perp 里，吃单首先要过保证金检查——你的可用保证金能否覆盖这笔成交带来的仓位变化？如果是 cross-margin 模式，这个检查还要考虑你账户内所有仓位的相互对冲。这个检查必须在撮合循环里同步完成，否则会出现"成交后才发现保证金不够"的状态不一致。
强平的特殊撮合通道是 perp 引擎最有意思的部分。当账户保证金率跌破维持线，强平引擎会接管——它会以账户的破产价（或某个保护价格）向订单簿发送 IOC 订单，试图把仓位平掉。如果订单簿太薄，吃不动这笔强平单怎么办？这里有几种工程选择：一是接入保险基金兜底，二是触发 ADL（自动减仓），由系统强制减少盈利对手方的仓位。
ADL 本质上是"撮合的最后一环"：当订单簿、保险基金都失效时，系统跳过订单簿，直接在两个账户之间做强制结算。这是一种把"撮合"概念从"自愿匹配"扩展到"非自愿匹配"的设计——它已经不属于传统意义上的撮合了，但它必须存在，否则系统在极端行情下会破产。
自成交防止（STP）的复杂化也是 perp 特有的。在现货里，自成交防止主要防止洗单；在 perp 里，同一个账户可以同时持有多空（hedge mode），所以 STP 的语义需要细分：是按 sub-account、按 user ID、还是按 master account？不同交易所选择不同。
总结一下：perp 撮合的"难"不在订单簿本身，而在订单簿后面那整套和风险引擎绑定的状态机。设计者必须想清楚：哪些检查在撮合主路径上（同步），哪些可以异步；强平的执行模型用什么；保险基金怎么计提；ADL 触发的优先级队列怎么排序（通常按"盈利百分比 × 杠杆倍数"排序，让最赚的、杠杆最高的人先被减仓）。
四、永续撮合的双路径：决策、构造、执行的分层
perp 撮合还有一层值得专门拎出来讨论：强平这条路径在撮合环节和普通订单合流，但在合流前后是另一套完全不同的逻辑。理解这层分层对设计或调试 perp 引擎至关重要——否则会反复混淆"撮合"和"清算"的边界。
把强平拆成三层来看：
第一层是触发判定。用 mark price——目的是"是否应该清算"这个决策不被订单簿瞬时操纵影响。这一层完全脱离场内深度，是一个独立的风控判断。
第二层是订单构造。强平引擎决定清算后，构造一个 IOC 订单送进订单簿。这个订单和用户的普通订单在多个维度上结构性不同：价格不是用户选的而是引擎按破产价作为限价；类型永远是 IOC 不允许 rest in book；手续费走清算费率（0.5–1.5%）而不是 taker 费率，且流向保险基金；下单权限属于系统而非账户——账户在被清算时甚至会先被强制撤销自己挂在簿上的所有挂单（避免自成交污染清算）；失败 fallback 不一样——用户 IOC 吃不到就消失，强平 IOC 吃不到则触发保险基金 → ADL 的级联。
第三层是撮合执行。一旦进入订单簿，强平 IOC 和普通 IOC 遵守完全相同的 price-time priority 规则去吃对手方流动性。这一层是对称的，撮合引擎不会"特殊对待"强平单的撮合优先级——撮合循环不该有这种 if-else，否则就破坏了 deterministic replay。
所以精确的描述是：撮合循环本身不分两套，但订单的来源、构造、计费、失败路径分两套。从撮合主路径的视角看，强平和普通订单是平等的；从事务全景看，它们走的是两条平行的管道，仅在撮合环节合流。
这里还有一个值得注意的点——mark price 决定"应该以什么价格清算"（触发条件），但 last price（场内深度）决定"实际能以什么价格清算"。当订单簿薄、深度跑光，强平 IOC 沿簿吃下来的实际成交价远差于破产价，这个 gap 就是保险基金的“盈亏来源”。保险基金本质是吸收"mark 给出的理论清算价"与"场内执行的实际成交价"之间的偏差。如果两者总是一致，保险基金根本不需要存在。
更激进的设计（Hyperliquid 的 HLP、dYdX 早期的 backstop liquidator 网络）干脆在订单簿前面加一层"清算市场"——让专门的做市商以约定折扣抢先接走整个仓位，绕开订单簿这条慢路径。这本质是把"强平执行"从场内撮合中完全独立出来，给清算路径自己的撮合通道。这是另一种回答双路径问题的方式：有些交易所认为两条路径塞进同一个订单簿是一种妥协，干脆让它们用不同的撮合通道。
回到 perp 撮合复杂性的核心：撮合主循环本身可以保持简洁，但它周围的状态机——风控、清算、保险基金、ADL、可能还有 backstop liquidator 网络——构成了一个比订单簿本身复杂得多的系统。"order book 长得和现货一样"的视觉错觉背后，实际上有两条独立的入口管道和四种不同的退出路径。这就是 perp 撮合"难"的真实形状。（据闻有些交易所还做了b book）
五、期权撮合：网格化与做市商主导
期权是这四类标的里唯一一个"标的物本身有数量爆炸"的类别。一个 BTC 现货市场只有一个订单簿；一个 BTC 永续也只有一个；但 BTC 期权——以 Deribit 为例——在任何一个时点都有几百个活跃合约，由 strike × expiry × call/put 三个维度组合出来。每个合约都需要独立的订单簿。
这就带来了第一个根本性问题：流动性稀疏。深度 in-the-money 或者 out-of-the-money 的合约一天可能只有几笔成交，订单簿上经常是空的或者只有做市商的两个挂单。这种稀疏性使得纯 LOB 模型几乎不可用——一个普通买家挂限价单可能要等几天才能成交。
行业的解法是混合三种模式：
LOB 用于流动性最深的合约，主要是 ATM 期权和近月合约。这部分和现货逻辑没本质区别。
RFQ（Request For Quote）用于流动性稀疏的合约。交易者发出报价请求，多个做市商响应，交易者从中选择最优。这套流程在 LOB 之外运行，撮合的是"询价单 vs 多个报价回复"，本质上是一个反向拍卖。
Block trade（大宗交易）用于超大单。两个对手方在场外谈好价格，把交易报到交易所登记结算，订单簿不参与撮合，只参与登记。
多腿同步撮合是期权撮合的另一个核心要求。一个常见的策略——比如 iron condor——需要同时买卖四个不同的期权合约。如果四条腿分别在四个订单簿上独立撮合，结果可能是其中两条腿成交了，另外两条没成交，交易者的风险敞口完全不是想要的。所以期权撮合引擎必须支持 combo book 或 multi-leg atomic execution：四条腿要么全部成交，要么全部不成交，作为一个整体处理。
Deribit 的做法应该算是目前行业参考标准：它有一个独立的 combo 订单簿，combo 订单可以独立挂单，也可以与单腿订单簿之间做 implied matching——系统会自动从单腿流动性合成 combo 价格，反之亦然。这是非常精妙的设计，但也意味着撮合主路径上要维护"虚拟订单簿"的状态同步。
举一个具体场景说明多腿同步撮合为什么不是可选项。ETH 现价 3,000，交易者预判未来 7 天震荡在 [2,900, 3,100] 区间，构造 Iron Condor：卖 3,100 Call、买 3,200 Call、卖 2,900 Put、买 2,800 Put。四条腿净收入是组合最大盈利，最大亏损因为有保护腿而被严格封顶——这是策略成立的前提。如果四笔订单各自独立提交到四个订单簿撮合，最常见的失败场景是：前两笔（call spread 部分）成交了，ETH 在毫秒间跳到 2,950，后两笔（put spread 部分）的对手方报价已经失效，做市商撤单或大幅调整，C、D 没成交。结果交易者持有一个裸的 call spread——方向性敞口完全反了，原本"震荡受益"的策略变成"看跌受损"，最大亏损也不再有界。Combo book 把四条腿打包成一个整体：要么全成要么全不成；implied matching 进一步让单腿订单簿的流动性可以被实时合成 combo 报价，反之 combo 订单簿的流动性也会回流到单腿，两层流动性互相补充。
做市商的定价算法主要用 IV Implied Volatility ，而不是价格（这也是期权特有的）。做市商不会挂"50000 strike call $1500"，他们会挂"buy at 65 vol, sell at 67 vol"，系统在每次报价生效时根据当前底层价格用 BSM（或更复杂的模型）计算出实际报价。这意味着做市商的报价是动态跟随底层的，订单簿在底层价格变动时会自动调整——这让"挂单"在期权里变成了一个连续函数而不是离散事件。
Greeks 化的组合保证金让风控也变得不同。在 perp 里，每个仓位独立算保证金；在期权里，做市商可能同时持有几百个合约，单独算每个合约的保证金会让资本效率低到无法运营。所以期权交易所通常采用基于希腊字母（delta、gamma、vega、theta）的组合保证金，把整个 portfolio 看作一个净敞口，按净 Greeks 计算保证金。这又反过来影响撮合——一笔成交的"保证金成本"取决于它是否对冲了你已有的仓位。
六、Polymarket 撮合：链上链下的混合架构
深入探讨之前之前先回答一个可能的质疑：为什么单列 Polymarket，为什么不讨论AMM? 而不是把它合并进一个泛化的"DEX 撮合"类别？
因为 Polymarket 的特异性不在"链上"这个标签上。Polymarket 真正独特的地方是三个机制的叠加：[0, 1] 价格钳制 + CTF 互补铸造 + UMA 结果判定（类似mark price）。这三个一起塑造了一种与现货、perp、期权和其他 DEX 都不同的状态机形态——价格空间离散有界、流动性来源无中生有、生命周期有终点。
下面按这三个机制和它们背后的信任假设为主线展开。
Polymarket 是一个（最先？）建在 Polygon 上的预测市场，所有头寸都是 ERC-1155 token，由 Gnosis 的 Conditional Token Framework（CTF）发行。一个市场——比如某个总统选举的二元预测——会发行两种 token：YES token 和 NO token，市场结束时一种 token 价值 $1，另一种价值 $0。
互补铸造机制是 CTF 的核心。任何人都可以存入 1 USDC，得到 1 YES + 1 NO。任何人也可以销毁 1 YES + 1 NO，赎回 1 USDC。这个机制的存在让做市商可以"无中生有"地为市场提供流动性——做市商不需要先持有 token 才能卖出，他可以即时铸造然后卖出。从撮合引擎角度看，这等价于做市商有一个无限的初始库存，但成本约束在保证金里——这是 Polymarket 与传统 CLOB 的一个关键差别。
链下撮合 + 链上结算是 Polymarket 的整体架构。具体流程：用户用 EIP-712 签名一个限价订单，发送到 Polymarket 的中心化撮合服务器；服务器维护一个传统的 LOB；当两笔订单匹配时，服务器把这两个签名打包成一笔链上交易，调用 exchange 合约完成结算。所以撮合本身是链下的（毫秒级），但结算是链上的（秒级）。
这个架构在 trust 层面有一个特别之处：撮合服务器不能伪造交易，因为它没有用户的私钥；但它可以审查交易——拒绝某些订单的撮合。
Gas 经济学塑造的是结算路径而不是用户行为。一个常见的误解是把 Polymarket 的 gas 成本归到用户身上——实际上 gas 是 relayer（Polymarket 的 operator）付的。用户用 EIP-712 签订单，relayer 在撮合后把成交批量提交上链，gas 由 Polymarket 承担，再通过交易手续费回收。这意味着对用户而言，挂单和撤单都是免费的——撤单甚至根本不上链，只是通知撮合服务器把订单移除，逻辑上和 CEX 撤单没本质区别。
但这不代表 gas 没有约束力，只是约束转移到了 relayer 一侧：每笔成交的链上结算成本由 Polymarket 承担，relayer 的 gas 预算 + Polygon 的吞吐上限共同决定了系统的最大成交频率。做市商在极端拥堵时感受到的不是"挂单贵"，而是结算延迟和吞吐瓶颈——这是和 CEX 完全不同的拥堵传导路径。
这个架构施加给撮合引擎的真正塑形是：必须让 relayer 能够把多笔成交批量结算（amortize gas），同时保持每笔交易在结算合约里独立可验证（防止 relayer 篡改或私吞）。所以 Polymarket 的 exchange 合约设计为接受"多笔签名订单 + 一笔批量提交"的结构。Gas 没有让 Polymarket 变成"低频市场"，但让它的撮合-结算耦合方式与 CEX 和纯链上 DEX 都不同——撮合层完全继承 CEX 的轻量化（毫秒撤单、零 gas 挂单），结算层却继承了链上 DEX 的可验证性约束。
预言机结果判定的终局性是预测市场撮合最特别的一点。其他三类市场都是"持续运行"的——价格永远在变，市场永远开放。但预测市场有一个明确的"终止时刻"：事件发生，结果被预言机（Polymarket 用 UMA 的 optimistic oracle）解析，YES 或 NO 被判定（也有被argue的时候，本文不讨论），所有持仓按 1:0 或 0:1 结算。这意味着撮合引擎要处理一个"市场冻结"的状态机：在解析窗口内禁止新订单，在 dispute 窗口内允许挑战，最终结算后停止所有交易活动。这个状态机在 CEX 现货里是没有对应物的。
价格被钳制在 [0, 1] 是另一个机制约束。这看起来是优势（不会爆仓到无穷），但这味着订单簿的价格档位空间有限——通常是 1 cent 一档，最多 100 档。这对撮合数据结构是一个强约束（你可以用一个 fixed-size array 而不是 tree），但也意味着价格发现的精度有上限。
举一个具体场景说明 mint/redeem 如何塑造做市行为。某市场 YES 报 $0.65、NO 报 $0.35（YES + NO 必然等于 $1，否则套利者立即 mint 或 redeem 拉平）。做市商 M 想为这个市场提供卖一流动性但手里没有 YES——他向 CTF 合约存入 100 USDC，瞬间得到 100 YES + 100 NO，把 100 YES 挂 0.66 卖、100 NO 挂 0.36 卖。两笔都成交后 M 持有 0 净敞口、赚到双边价差 0.02 × 100 = 2 USDC。这就是 Polymarket 做市的标准玩法：用 mint/redeem 把"资本占用"换成"双向报价利差"。
值得专门分析的是：YES + NO = 1 这个不变量撮合引擎不需要主动维护，是市场结构通过套利者自动保证的——这种"市场结构自带的不变量"在传统 LOB 里是不存在的，做市商也不可能做到"手里没有库存就能卖"。Polymarket 撮合引擎的设计因此可以省掉一些 CEX 必须的库存约束检查，但代价是必须把 mint/redeem 路径作为一等公民集成进结算合约。
总结一下 Polymarket 撮合的特异性：信任假设是"链下撮合+链上结算"的混合，token 模型是 CTF 的互补铸造，价格空间是 [0,1] 的有界离散，时间维度是有终局的，gas 由 relayer 承担并通过手续费回收。这些约束加起来产生了一种与前三种完全不同形态的撮合引擎。
七、差异从何而来：一个五维框架
把这四种形态铺开看，可以提炼出五个维度来解释为什么撮合引擎在不同标的下分化：
将五维框架放到"撮合-风控耦合度"和"流动性密度"两个维度上，四种形态的位置一目了然：现货在低耦合高密度的舒适区，永续在高耦合高密度（最复杂的工程现实），期权在高耦合低密度（必须用 RFQ + combo 弥补稀疏），Polymarket 落在中间——耦合度被链上结算抬高了，密度被互补铸造拉上来了。
每个维度都对撮合引擎施加压力：
资产形态决定了订单簿的数量和稀疏度。单维同质（现货、perp）只需要一个簿，多维稀疏（期权）需要几百个簿且必须解决 sparsity，离散互补（Polymarket）需要把"铸造/赎回"集成进撮合路径。
结算时序决定了状态机的复杂度。即时同步（现货）让撮合等于结算；持续记账（perp、期权）需要维护持仓状态、保证金状态、PnL 状态，并在每次撮合后更新；终局解析（Polymarket）需要状态机从"开放"到"冻结"到"解析"的转换。
风险拓扑决定了风控耦合度。线性零持仓（现货）几乎不需要风控；线性持续敞口（perp）需要 pre-trade margin check 和 liquidation engine；凸性（期权）需要 Greeks-based 组合保证金；二元有界（prediction）几乎不需要风控（最大损失就是已支付的钱）。
流动性密度决定了流动性来源策略。高密度市场可以纯 LOB；稀疏市场必须引入 RFQ、AMM、做市商激励等补充机制。
信任边界决定了哪些组件必须可验证。CEX 中所有组件都在交易所内部；纯 DEX 中所有组件都在链上；混合架构中需要明确什么必须上链（结算）、什么可以离链（匹配）、攻击模型是什么（无法盗钱但可审查）。
八、没有一步是多余的：撮合是机制的镜子
回到开头的问题——为什么"撮合引擎"在不同市场分化成四种几乎不同的机器？
因为撮合从来不是一个独立的工程模块，它是标的物自身性质、结算模型、风险结构、流动性形态、信任假设这五个变量综合作用的产物。撮合引擎是这些变量的样貌——你看到撮合长什么样，反过来就能推出这个市场的金融结构是什么样。
现货撮合的简洁，对应的是"同质资产 + 一次性结算 + 零持仓延续"的干净结构；
永续合约撮合的复杂，对应的是"合成资产 + 持续敞口 + 风控-撮合深度耦合"的工程现实；
期权撮合的混合形态，对应的是"维度爆炸 + 流动性稀疏 + 做市商主导"的市场结构；
Polymarket 撮合的链上链下分裂，对应的是"无审查"与"抗盗窃"两个安全目标的工程妥协。
如果说清算是交易所的良心，那么撮合机制就是交易所的底线。
