Go标准库time.Timer/Ticker不基于红黑树，因其用四叉最小堆（timerHeap）精准适配运行时模型：处理大量同毫秒定时器更稳定，插入/删除常数更低且缓存局部性好；红黑树缺乏必要支持且易引发并发与时间回拨问题。
Go 标准库的 time.Timer 和 time.Ticker 不基于红黑树，也不支持直接替换为红黑树容器——你没法通过改配置或换包实现“基于红黑树的高性能定时器”，必须重写调度内核。
为什么 container/heap + slice 就够用，而红黑树反而容易翻车
标准库用四叉最小堆（timerHeap）不是权衡失误，是针对 Go 运行时模型的精准适配：
-
time.Now().UnixNano()作为 key 时，大量定时器集中在同一毫秒，最小堆插入重复 key 的开销稳定；红黑树需额外处理等值节点顺序，否则Less仅比时间戳会导致内存地址决定顺序，回调执行不可控 - 网络服务中定时器生命周期短、创建/销毁频繁（如连接超时），
heap.Push/heap.Pop平均常数比红黑树旋转+变色低 30%~50%，且 cache 局部性更好 - 标准库没有
container/rbtree；第三方泛型红黑树包（如golang.org/x/exp/constraints）缺哨兵节点、无rbtree_min()快速取顶、不支持 remove-by-pointer，一并发就删错节点
硬要用红黑树？必须重写三个关键接口
不是“把定时器塞进树里”就行，而是要对齐 Go runtime 的时间推进逻辑和 netpoll 驱动方式：
-
Add(d time.Duration, f func()) *TimerNode：必须用绝对时间戳（毫秒级int64）作 key，不能传相对 delay；插入时需带单调递增seq字段，避免等值 key 下排序随机 -
Stop(id uint64)：不能只靠 key 查找删除——同一时刻可能有多个定时器，必须持有原始*rbtree.Node指针，否则 Stop 时可能删掉刚插入还没触发的那个 -
Tick(now int64)：只遍历最左路径（rbtree_min()起始），逐个弹出 ≤now的节点；不能二分查找或全树扫描，否则 O(n) 毁掉性能
红黑树定时器根本不在树上运行，而在 epoll 或 netpoll 里驱动
树只是容器，真正决定“何时唤醒、唤醒多少、谁来执行”的是 I/O 多路复用层：
- 错误做法：
for { time.Sleep(1 * time.Millisecond); t.Tick(time.Now().UnixMilli()) }—— 时间不准、CPU 空转、无法响应系统时间回拨 - 正确做法：每次从树顶取
rbtree_min().when，调用epoll_wait(epfd, events, timeout)或runtime.netpoll(delay)阻塞等待；唤醒后批量处理所有 ≤ now 的节点 - 必须处理时间回拨：若检测到
now > rbtree_min().when，说明 NTP 校正发生，需遍历树强制标记所有when 的节点为过期，而非等待下一轮 Tick
红黑树定时器最难的不是写树，是让树的 when 字段语义与 runtime.timer.when 对齐，且在 sysmon 扫描、adjusttimers 调整、netpoll 唤醒之间不产生竞态——这些细节标准库没暴露，文档也几乎不提。
