← 返回索引 · 2026-02-05 · 0002

STP（自我成交防止）：撮合引擎里的合规与性能平衡（摘要）

原文首发于 TechNova：从撮合引擎到合规风控：自我成交防止（STP）机制的深度剖析与实现

承接页（交易系统解决方案）：https://technologynova.org/solution/

TL;DR

STP 是撮合事务的一部分：必须在生成成交回报前、订单簿状态更新的同一原子流程中完成判断。
判断本身很便宜（O(1)）：核心是 UserID（或更严格的 EntityID）比较；真正的坑在于内存布局与迭代删除的正确性。
策略要可配置：常见三类——取消新单、取消老单、两者都取消；不同用户（尤其做市商）偏好不同。

1. STP 解决的到底是什么问题

自我成交（Self-Trade）指同一交易主体的买单与自己的卖单撮合。轻则造成手续费损失与策略“自相残杀”，重则被用于刷量（Wash Trading）操纵市场。因此 STP 既是合规要求，也是市场公平与用户体验的底层保障。

2. 为什么 STP 必须放在撮合引擎内部

很多人直觉是“前置风控拦掉”，但前置风控看不到订单簿的实时对手方。只有撮合引擎在撮合瞬间，才知道 aggressor（吃单）将与哪一笔 resting（挂单）成交。所以 STP 必须嵌入撮合循环：当价格条件满足准备撮合时，先做 STP 判断，再决定是否生成成交。

3. 策略：取消新单 / 取消老单 / 取消两者

CANCEL_NEWEST：取消主动吃单（新单）。默认最常见，实现也最直观。
CANCEL_OLDEST：取消订单簿上的挂单（老单）。做市商常更偏好这种，保护其挂单流动性布局。
CANCEL_BOTH：两者都撤。用于更严格的防刷量/合规模式。

工程要点：如果你在迭代订单簿时删除元素，必须用“可安全删除”的迭代器/数据结构，否则很容易出隐蔽 bug。

4. 性能与实现：关键不在 if，而在数据局部性

字段内联：把 UserID（最好是 uint64）直接放进 Order 结构体，避免指针跳转导致 cache miss。
只在“价格可交叉”时检查：别为了 STP 去扫描订单簿。
单交易对单线程事件循环更自然：撮合+STP 原子化，避免锁与并发写订单簿的复杂度。

5. 架构演进：从 UserID 到 EntityID（更严格但仍要 O(1)）

当监管要求提升到“同一最终受益人（UBO）旗下多账户也禁止自成交”，就不能只比 UserID。推荐做法是：在订单进入撮合引擎之前完成“身份丰富化”（UserID → EntityID），让撮合环路里仍然是 O(1) 比较。 反模式是在撮合循环里 RPC 调用外部合规服务——那会把延迟直接炸穿。