必须用 std::map（或 std::multimap），因其天然有序，支持O(log n)最优价格查找、区间扫描和稳定遍历；哈希表无序且浮点键哈希不稳定，不满足撮合引擎“价格优先、时间优先”核心需求。
限价订单薄用 std::map 还是 std::unordered_map？
必须用 std::map（或 std::multimap），不能用哈希表。撮合引擎的核心操作是「按价格优先、时间优先」匹配，而价格是天然有序的——买盘从高到低、卖盘从低到高。每次新订单进来都要找最优对手价（begin() 或 rbegin()），撤单/部分成交后还要快速定位相邻价格档。哈希表不支持有序遍历，也无法 O(log n) 找到最接近某个价格的档位。
常见错误是图快用 unordered_map<double orderlist></double>，结果发现：std::equal_range 失效、无法做价格区间扫描（比如市价单扫到某价位止）、回测重放时因浮点键哈希不稳定导致行为不一致。
- 价格键必须用整型（如以最小变动单位为单位的
int64_t），避免double作为map键带来的精度和比较问题 - 同一价格可能有多个订单，所以用
std::map<pricelevel std::deque>></pricelevel>或自定义链表更稳妥，别依赖multimap的插入顺序保证（C++ 标准不保证同键元素的插入序） - 如果追求极致性能且价格档稀疏（如加密货币 tick 很小），可考虑跳表（
skiplist）替代map，但绝大多数场景map足够且更易维护
订单节点该存指针还是对象？内存怎么配对释放？
订单节点必须存裸指针（Order*）或智能指针（std::unique_ptr<order></order>），不能把 Order 对象直接塞进 deque 或 list。原因很实际：订单生命周期独立于订单薄——它可能被撤单、跨多个簿（如跨合约套利）、或需记录完整生命周期日志。一旦对象被拷贝进容器，地址就失控，后续撤单时无法精准定位和移除。
典型坑是：用 std::deque<order></order> 存对象，然后在撤单函数里传入 order_id 去遍历查找——这变成 O(n) 搜索，实盘中几十万订单下直接卡死。
立即学习“C++免费学习笔记（深入）”；
- 订单创建时统一由内存池（
boost::pool或自研 slab allocator）分配，避免频繁new/delete；订单薄只持指针，不负责析构 - 撤单必须靠
order_id → Order*的反向哈希索引（std::unordered_map<orderid order></orderid>），查表O(1)定位，再根据Order::price_level找到对应价格档的容器，用迭代器erase() - 禁止在订单薄结构里保存冗余字段（如重复存 price），所有关键字段都从
Order*实例读取，保持单一信源
买卖盘分离还是共用一个结构？如何避免锁竞争？
买卖盘必须物理分离：两个独立的 std::map（bid_book 和 ask_book）。共用一个结构看似省事，但会强制所有操作加全局锁——下单、撤单、撮合全串行，吞吐直接归零。实盘中买卖盘更新频率差异大（如高频做市商主要挂 ask，套利者猛扫 bid），分离后可用细粒度锁甚至无锁设计。
常见误操作是用一个 std::map<:pair price>, OrderList></:pair>，结果 Side 枚举值混在键里，导致无法单独遍历 bid 或 ask，也丧失了 bid_book.rbegin() 这种天然最优买价访问能力。
- 每个盘（
bid_book/ask_book）配独立读写锁（std::shared_mutex），撮合线程只读，下单/撤单线程写；若用 C++17 及以上，优先考虑std::shared_mutex而非pthread_rwlock - 绝不允许跨盘操作时同时锁两个结构（如“先锁 bid 再锁 ask”），必须约定固定顺序（如总是先锁
bid_book再锁ask_book）防死锁 - 如果追求零锁（如 LMAX Disruptor 风格），订单薄本身只做无锁 ring buffer 的消费者，所有变更走事件队列，但复杂度陡增，中小系统不推荐
订单薄要不要持久化或快照？内存结构如何适配？
订单薄本身不存快照，快照是外部组件按需拉取的视图。内存结构必须支持高效只读遍历（const_iterator）和原子性快照——即在任意时刻能 O(1) 获取当前全部价格档列表，且不阻塞写操作。这意味着不能用带写时复制（copy-on-write）的结构（如某些封装过的 map），也不能在遍历时锁整个簿。
很多团队过早引入快照序列化逻辑，结果发现：序列化耗时占撮合周期 20%+，或快照过程中订单状态已变更，导致风控模块看到脏数据。
- 快照应由专用线程定时触发，调用
bid_book和ask_book的cbegin()/cend()遍历，逐档拷贝价格和总数量（不是每个订单），生成轻量结构（如vector<snapshotlevel></snapshotlevel>） - 订单薄内部不存任何与快照相关的字段（如版本号、快照标记位），这些由快照服务自己管理
- 如果需要磁盘回放（如灾备），订单流本身应走 WAL（write-ahead log），而不是定期 dump 订单薄内存——因为簿是派生状态，log 才是事实来源
真正难的从来不是怎么存，而是怎么让“价格有序性”、“多线程安全”、“低延迟遍历”三者不互相拖累。多数崩塌发生在把订单薄当成通用容器来用，忘了它本质是个实时决策索引——一切设计，得先问一句：这个改动会让最优对手价的查找变慢吗？
