订单簿里的红黑树：只管价档，不管订单

读内存撮合库时，很容易把红黑树想成「所有订单都挂在树上」。它不是。树只索引价档，不索引单笔订单。 键是价格，值是该价的 OrderQueue。找某一档用旁边的 prices map；树只负责「谁最贵 / 谁最便宜 / 下一档是谁」。

它长什么样

卖盘按价格从低到高排：

    101
   /   \
100     103
       /
     102

每个节点：price → *OrderQueue（该价上的 FIFO 订单）。

撮合时：卖单入口先 GetMin() 拿到 100，吃完这一档再 GreaterThan(100) 走到 101。买盘反过来：GetMax() + LessThan。新价格出现时 Put，档空了 Remove。

节点大概是：key（价格）、value（队列）、左/右孩子、红或黑。二叉搜索树保证左 < 自己 < 右；红黑规则把树高压在大约 2 log n，避免按顺序挂价时退化成一条链。

结构	问题
只有 `map`	查已知价格很快，但找不到最优价和「下一档」，只能扫全部键
排序切片	最优价 O(1)，但中间插入/删除一档要搬数组，价档一多就慢
堆	只要最值可以，任意删一档、找后继价都很别扭
不平衡 BST	价格常按顺序来，会退化成链表
AVL	也能用，查稍快、增删稍慢；价档增删更频繁，红黑树更常见（C++ `map`、Java `TreeMap` 也是它）
B 树	为磁盘设计，纯内存没必要

一笔订单本身在链表里，时间优先靠 FIFO，不需要树。树只解决「价格有序」这一个问题：价档数量通常远小于订单数，O(log 档数) 的最值/后继足够快。

下一篇把 prices map、撮合怎么走档、红黑是什么、以及为什么是 O(log 档数) 拆开说。